Контролер пов`язують об`єктів

Розробка програми контролера автоматично пов'язують об'єктів для керування конструкторської документацією в середовищі Windows 95/NT.

АНОТАЦІЯ

У даній дипломній роботі здійснено розробку програмного продукту, для середовища операційної системи Windows 95/NT, що забезпечує створення, редагування та виконання функцій автоматично пов'язують об'єктів систем автоматизованого проектування або будь-яких інших пакетів прикладних і системних програм підтримують механізм скріплення і впровадження.

Розроблений програмний продукт дозволяє поєднувати функції автоматично пов'язують об'єктів систем проектування в один проект з файлами даних цих систем проектування, таким чином будучи інтеграційним ланкою між різними програмними продуктами.

В даний час на тлі загальної комп'ютеризації всіх виробничих, торговельних і побутових галузей з одночасним збільшенням конкуренції на комп'ютерному ринку, у зв'язку з прискоренням розробок все більше нових технологій виробництва обчислювальної техніки, все більшого значення набуває розробка і виробництво конкурентоспроможної обчислювальної техніки. Сьогодні це стає можливим тільки при використанні сучасних засобів проектування електронних обчислювальних засобів (ЕВС). Сучасні засоби конструювання неможливо уявити собі без комп'ютерних засобів проектування. Комп'ютери мають великий потенціал у області проектування ЕВС.

Комп'ютерні засоби проектування, окрім безпосередньо комп'ютерного обладнання, включають в себе програмне забезпечення. На нинішньому етапі розвитку програмного забезпечення систем проектування, є багато розробок систем автоматизації проектування. Ринок програмного забезпечення насичений великою кількістю різноманітних пакетів прикладних програм включають в себе різні інструментальні засоби, що дозволяють багато в чому спростити роботу конструктора ЕВА. Зараз у нас в країні і за кордоном найбільш поширені такі пакети програмного забезпечення, як PCAD, AutoCAD, MicroCAPS, Pspice, MathCad та інші. Ці програмні засоби дозволяють автоматизувати складні і одноманітні процеси присутні на багатьох етапах проектування ЕВА. Наприклад, різного роду математичні розрахунки всілякої складності, логічне моделювання схем, розробка топології мікросхем, розводка друкованого монтажу друкованої плати, створення готових конструкторських документів високої якості і т.д.

Зростання популярності автоматизованих систем проектування виник багато в чому завдяки поліпшенню призначеного для користувача інтерфейсу програмного забезпечення в цілому і систем проектування зокрема. За останні кілька років у розробників програмного забезпечення всі великі симпатії викликає платформа Windows для створення високо якісних програмних продуктів надають користувачу найбільш зручний для сприйняття інтерфейс. Зручність інтерфейсу Windows пов'язано з високими вимогами з ергономічної точки зору пред'явленим творцями Windows до своєї операційної системи. Свою систему Windows фірма Microsoft створила для платформи IBM, не випадково. Треба відзначити значну популярність у світі комп'ютерів сумісних з IBM AT. Стала в наш час своєрідним світовим еталоном поєднання якості і низької ціни. Більше половини комп'ютерного ринку належить комп'ютерів сумісним з IBM AT.

Однак, будь-який пакет програм не може забезпечити повну універсальність своєї системи, але це власне не до чого. Будь-яке програмне забезпечення, завдяки своїй специфічності в тій чи іншій області автоматизації проектування, дозволяє отримати максимальну ефективність конкретно у своїй області. Але, останнім часом намітилася тенденція до інтеграції програмного забезпечення на базі так званих автоматично пов'язують об'єктів. Цей термін насправді означає не інтеграцію програм у прямому сенсі, а лише її емуляцію. Тим не менш, для кінцевого користувача це виглядає як повна інтеграція програмного забезпечення різних напрямків і різних фірм розробників програмного забезпечення. Ідея полягає в тому, що будь-який додаток для Windows, що забезпечує OLE Automation (Objekt Linking and Embedding Automation - автоматичне зв'язування та впровадження об'єктів), може управлятися ззовні іншими додатками, які користуються ним грунтуючись на наданих додатком програмних інтерфейсах і таким чином виконувати ті ж функції , що і додаток прабатько функцій.

Завданням даної дипломної роботи є розробка універсальної середовища проектування. Для інтеграції систем проектування і дозволяє створювати складовою документ, який може включати в себе всі види документів оброблюваних інстальованими в дану систему додатками забезпечують OLE Automation, і максимальну емуляцію OLE Automation для всіх інших додатків. А також виконувати будь-які функції OLE Automation зареєстровані додатками.

1. АНАЛІЗ ТЕХНІЧНОГО ЗАВДАННЯ

1.1. Вибір та обгрунтування операційної системи

1.1.1. Графічні операційні системи

Найбільш поширеною середовищем програмних продуктів нині по праву є Windows, розроблена корпорацією Microsoft в розрахунку на широке коло користувачів.

Windows пропонує користувачу віконний інтерфейс, в якому кожною виконуваною програмі приділяється екранне вікно яке може займати частину екрану або весь екран. Програми, спеціально спроектовані для таких віконних середовищ, можуть користуватися всіма їх перевагами. Вид користувацького екрану з перекриваються вікнами різних прикладних програм досить наочно демонструють можливості середовища з одночасного використання декількох програм і передачу даних між ними (рис. 1.1).

Користувач працює з додатком, що знаходяться самому "верхньому" вікні, але простим клацанням миші на іншому вікні він може активізувати іншу програму. Крім того, вже у своїх ранніх версіях Windows дозволяла копіювати інформацію з вікна однієї програми у вікно іншої програми за допомогою засобу clipboard - буфера обміну.

Графічний режим Windows, як і графічний режим будь-якій іншій операційного середовища (Windows NТ, ОS / 2, Soleras, Motif) має мало спільного з знакоместним графічним режимом, доступним у багатьох програмах для МS-DОS, завжди розміщують на екрані стандартна кількість символів, наприклад 8Оx25 або 80x43. Windows (а отже, і будь-яка Windows-програма) позиціонує графічні об'єкти з точністю до пікселя.

Розміри таких об'єктів Windows, як елементи вікон, кнопки та значки стандартизовані. Для відображення системних повідомлень і найменувань команд меню Windows застосовує відповідні растрові (матричні) шрифти, що мають різні типорозміри для роботи в режимах низького і високого дозволу. Для підготовки документів, що містять текст, Windows дозволяє використовувати масштабовані шрифти, вживані як для екранного виведення, так і для роздруківки па принтері. Завдяки цьому в процесі підготовки документа можна бачити на екрані практично те ж, що буде отримано на папері.

Графічна підсистема Windows використовує універсальні методи звернення до будь-яких графічних пристроїв виведення, будь то відеосистема ЕGА або super VGA, лазерний принтер або автомат для виведення друкарських форм. Стандартизований інтерфейс Windows, звичайно, не з самими дисплеєм і принтером, а з драйверами цих пристроїв, причому драйверів в комплект постачання системи Windows входить велика кількість.

Випуск графічної операційної оболонки Microsoft Windows 3.0 став головною подією 1990 року на програмному ринку, затьмарив одночасна поява IBM OS / 2 1.3. Крім приємного інтерфейсу середовище Windows надавала значний комплекс послуг.

З системою поставлялося велика кількість драйверів для самих різних моделей пристроїв введення-виведення, таких як відеоадаптери та принтери. Найширший апаратна сумісність була одним з факторів успіху Windows. Комплект Windows 3.0 містив кілька варіантів драйверів для різних моделей клавіатур, мишей і відеоадаптерів і велика кількість драйверів принтерів. У Multimedia для Windows 3.0, а потім у Windows 3.1 з'явилися драйвери звукових карт, МIDI пристроїв і синтезаторів. Кількість найменувань підтримуваних пристроїв швидко зростала ...

1.1.2. Windows 3.х

З точки зору масового користувача, не розпещеного OS / 2, Windows 3.0 була дійсно передовий середовищем. Вона використала весь обсяг пам'яті, що адресується мікропроцесорами 80286, 80386 і вище. З 32-розрядними мікропроцесорами (80386 і вище) і при наявності не менше 2 Мбайт пам'яті Windows 3.0 могла використовувати віртуальну пам'ять, тобто працювати з деяким простором на жорсткому диску як з продовженням оперативної пам'яті комп'ютера, розміщуючи в ньому дані і код програм.

Windows мала багатозадачні можливості з кооперативним використанням процесорного часу "одночасно" працюють додатками. Кооперативну

багатозадачність можна назвати багатозадачністю "другого ступеня" оскільки вона використовує більш передові методи, чому. просте перемикання завдань, реалізоване багатьма відомими програмами (наприклад, МS-DOS shell з МS-DOS 5.0 при простому переключенні активна програма отримує все процесорний час, а фонові програми повністю заморожуються. При кооперативної багатозадачності додаток може захопити фактично стільки процесорного часу, скільки вона вважає за потрібне. Всі додатки ділять процесорний час, періодично опитуючи один одного.

З іншого боку, режим кооперативної багатозадачності менш досконалий, ніж режим поділу часу, званий також витісняючої багатозадачністю. При витісняючої багатозадачності програми споживають рівно стільки процесорного часу, скільки їм належить, а не скільки заманеться. За виділення процесорного часу тому чи іншому додатком відповідає тільки операційна система, керуючись поточними пріоритетами. Завдяки цьому при витісняючої багатозадачності можна в будь-який момент перемкнутися на будь-який процес, на відміну від кооперативної багатозадачності, при якій для перемикання між програмами може знадобитися суттєва пауза. При витісняючої багатозадачності здається, що процеси дійсно працюють одночасно, хоча це насправді і не так, - в усякому разі, на комп'ютері з одним мікропроцесором, яким є звичайний IВМ РС.

З квітня 1992 року Windows 3.1 офіційно іменується операційною системою. Інтерфейс її був трохи поліпшений, зокрема були посилені можливості управління екранними об'єктами мишею (Drag - and - drop метод перетягування). Windows стала безпосередньо підтримувати динамічний обмін даними між додатками (DDЕ - Dynamic Data Exchange). У систему увійшли засоби мультимедіа, раніше постачалися окремо в пакеті Windows Multimedia Extension. Для розширення видавничих можливостей у Windows була вбудована підтримка системи масштабування шрифтів TrueType.

Windows 3.11 for Workgroups ("для робочих груп") позиціонувалася як самостійна мережева операційна система для одно-рангової локальної мережі, а також як мережевий клієнт для сервера Windows NТ. В іншому Windows 3.11 для робочих груп була злегка покращуваною модифікацією Windows 3.1, що працює тільки в 386-м Розширеному режимі на 32-розрядних мікропроцесорах.

А тепер ми постараємося розібратися в тому, як влаштована Windows.

Режими роботи Windows 3.X Щоб запустити мотор Windows на повну потужність, звичайно, потрібні насамперед мегабайти і мегабайти оперативної пам'яті. Але їх неможливо використовувати на мікропроцесорах 8088/86. Не надто вдалим рішенням був і захищений режим 80286: для того щоб використовувати на комп'ютері додатки для нової операційної середовища разом з МS-DOS додатками, доводилося перемикати мікропроцесор із захищеного режиму до реального і назад.

Тут доречно згадати про те, що фірма Microsoft вельми тісно співпрацювала з Intel під час розробки мікропроцесора i80386. Microsoft фактично нав'язала інженерам Intel власну концепцію режиму віртуального мікропроцесора 8086-V86, найбільш зручну для розробки операційної системи, що використовує МS-DOS додатки разом з програмами захищеного режиму. Оскільки в 1990 році ринок ще не був готовий до повного переходу на операційну систему для мікропроцесора 80386, Windows 3.О могла функціонувати в трьох режимах, в кожному з яких мікропроцесор і пам'ять використовувалися по-різному.

У реальному режимі роботи Windows система функціонувати навіть на комп'ютері з мікропроцесором 8088 чи 8086, обладнаному лише звичайною пам'яттю для роботи додатків в реальному режимі Windows 3.0 використовувалася тільки звичайна пам'ять МS-DOS і відображається пам'ять.

Стандартний режим Windows 3.0 вимагав для роботи мікропроцесор 80286 і всього 1 Мбайт пам'яті - 640 Кбайт стандартної і 384 Кбайт додаткової (справжня робота починалася при обсязі пам'яті 4 Мбайт). Для додатків Windows використовувалася розширена пам'ять (ХМS). Для програм МS-DOS, що завантажуються з-під Windows, застосовувалася звичайна пам'ять і перемикання мікропроцесора із захищеного режиму до реального.

Більш повно використовував апаратні ресурси 386-й Розширений режим Windows. У цьому режимі версії Windows 3.0 та 3.1 працювали з віртуальною пам'яттю, мав приблизно втричі більший обсяг, ніж фізична оперативна пам'ять. Додатків МS DOS в 386-м Розширеному режимі відводилася особлива форма пам'яті, яка у віртуальному режимі 8086 размечались як звичайна пам'ять MS DOS. За замовчуванням МS-DOS програми завантажувалися займаючи, як зазвичай, весь екран, але могли бути переведені в графічне вікно - стандартне вікно Windows. Програми МS-DOS, запущене з-під Windows в 386-м Розширеному режимі, працювало у віртуальній машині, іншими словами, вважало себе завантаженим на своєму власному комп'ютері і знати не знало про існування Windows.

Зрозуміло, для роботи в 386-м Розширеному режимі потрібний комп'ютер з мікропроцесором не нижче 80386. Оголошені вимоги до обсягу пам'яті (2 Мбайт) знов-таки не варто було приймати всерйоз. Мінімумом були 4 Мбайт пам'яті, а для більш-менш серйозної роботи були потрібні 8 Мбайт або більше.

Структура ядра Windows. Спосіб, за допомогою якого одна і та ж система може працювати в трьох принципово різних режимах, орієнтованих на абсолютно різні мікропроцесори, полягає в наступному.

Ядро Windows складається з трьох компонентів Kernel, User і GDI. За допомогою додаткових DLL-файлів (динамічно завантажуваних бібліотек) підтримуються відображенням стандартних діалогових вікон, протоколи DDЕ (динамічного зв'язування даних) і ОLЕ (зв'язування і вбудовування об'єктів), взаємодія з драйверами пристроїв введення-виводу і інші риси Windows. Windows-драйвери пристроїв бувають, до речі, двох видів - "звичайні" DLL-драйвери і 386драйвери, останні призначені знову-таки для роботи тільки в 386-м Розширеному режимі Windows.

Найбільш низькорівневої частиною ядра Windows є модуль Kernel, керуючий розподілом пам'яті, процесами, файловим введенням-виведенням і так далі. У різних режимах роботи Windows 3.О функції Kernel виконували різні файли: kernel.ЕХЕ для Реального режиму krnl286.Еxe для Стандартного режиму, КrnlЗ86.ЕХЕ для 38б-го Розширеного режиму.

Так що Windows 3.0 була розроблена як операційна система, що має три різних ядра. Коли був скасований Реальний режим роботи, з комплекту поставки Windows 3.1 і зник файл Kernel.dll. Наступний крок був зроблений, Windows 3.11 для робочих груп - ця система працювала тільки в 386-м Розширеному режимі. Модуль User (user.ЕХЕ) служить для роботи з клавіатурою, мишею, таймером і портами, а також виконує функції відображення елементів графічного інтерфейсу (вікон, меню). Він управляє такими драйверами, як, наприклад, різні драйвери клавіатури і миші.

Нарешті, модуль GDI (інтерфейс графічних пристроїв, файл GDI.ЕХЕ) підтримує графічні процедури - промальовування ліній, зафарбування, відображення шрифтів (починаючи з Windows 3.1 - всі операції зі шрифтами TrueType) і взаємодіє з драйверами графічних пристроїв - дисплея і принтера. З Windows 3.1 поставлялося більше десятка драйверів відеоадаптерів. Для підтримки принтерів в Windows 3.1 вперше була застосована архітектура міні-драйверів. Універсальний драйвер принтера NIDRV.DLL виконував апаратно-незалежні функції друку-кілька десятків міні-драйверів, що поставляються виробниками, доповнювали універсальний драйвер функціями обхідних спеціально для підтримки конкретних пристроїв і не повторювали вже написаний загальний код.

1.1.3. Windows 95

У 1996 році фірмою Microsoft, була випущена наступна версія операційної системи Windows. Яка була названа фірмою 32 розрядної багатозадачного графічною системою. / 1 /

Архітектура Windows 95. Що повинна була зробити Microsoft, щоб прийти до 32-розрядної операційної системи із забезпеченням витісняючої багатозадачності, яка б при цьому залишалася повністю сумісна з прикладними програмами для Windows 3.x і MS-DOS, не вимагала б для роботи самої МS DOS і "вміщувалася" у чотирьох мегабайтах оперативної пам'яті?

Фірмою Microsoft вже випущені системи, що задовольняють самим серйозним вимогам до управління пам'яттю і процесами, - Windows NТ SERVER і Windows NТ workstation (випущені версії 3.51 і готуються до випуску 3.52), Однак ці системи самі пред'являють серйозні вимоги до апаратури, а заодно і до користувача . Windows NТ SERVER призначається не для десятків мільйонів споживачів Windows, а для мережного адміністрування. Windows NТ workstation потрібна тим користувачам, які використовують додатки з високою інтенсивністю обчислювальної обробки, тим, хто потребує високого ступеня безпеки даних, і тим, хто більше турбується про надійність системи, ніж про сумісність з додатками для MS DOS і Windows 3.x.

Всіх інших користувачів на порядок більше, і їм потрібніше "легка" система.

Ядро Windows 95. Ядро Windows 95, як і у всіх попередніх версіях Windows, має трирівневу структуру Kernel-User-GDI. Всі ці модулі повинні б бути 32-розрядними, але в дійсності повністю 32-розрядною зроблена тільки сама низькорівнева частина ядра Windows 95 - Кегне1. Цілком зрозуміло, що, оголошуючи про 32-розрядної системі, Microsoft зобов'язана була виконати в 32-розрядному коді хоча б такі базові речі, як функції введення-виведення, управління пам'яттю і процесами, підтримку мережевої і файлової систем.

Що стосується двох інших модулів ядра, то розрахунки показали, що повністю 32-розрядні USER і GDI разом зажадають для роботи понад 1 Мбайт пам'яті, Windows 95 використовує 1б-розрядний код, коли він необхідний для забезпечення сумісності або якщо 32-розрядне кодування недоцільно, тобто збільшило б витрата пам'яті без помітного збільшення продуктивності.

Тому модуль User, залишився в Windows 95 переважно 1б-розрядним, а його 32-розрядна частина використовується для переадресації викликів 32-розрядних додатків 16-розрядному блоку. Більша частина функцій Ов1, включаючи підсистему буферизації вхідних і вихідних потоків, підсистему друку, растеризатор шрифтів TrueТуре та основні операції малювання, перенесена в 32-розрядний модуль, що залишився 16-розрядний код описує управління вікнами. 16-розрядні функції ядра Windows 95 написані переважно на асемблері. Що ж стосується Kernel, то його 16-розрядна частина задіюється тільки при завантаженні Windows 95 і використовується тільки для ініціалізації 32-розрядної частини Kernel. Сам Kernel32 ніколи не звертається до Kernel16. На рис.1.2. показано, для яких функцій використовується 32-розрядний код, а для яких 16-розрядний код модулів ядра Windows 95.

Багатозадачність. Аналізуючи виконання під Windows 95 16-розрядних додатків для Windows 3.x і МS-DOS, ми бачимо здебільшого знайомі, хоча і серйозно поліпшені методи Windows 3.x.

Як показано на рис. 1.3., 16-розрядні програми для Windows ("додатка win16") виконуються в загальному просторі адрес у межах системної віртуальної машини. Такі варіанти, як виконання кожної програми win16 в окремій віртуальній машині (що можливо в ОS / 2) або повна емуляція Windows 3.x в межах операційної системи (як це робиться у Windows NТ).

32-розрядні додатки, створені з урахуванням вимог Windows 95 ("додатка win32"), виконуються в режимі "справжньої" витісняє багатозадачності. Крім того, Windows 95 підтримує багатопотокові програми, здатні запускати паралельно кілька процесів.

Для кожного win32-додатки і для області адрес додатків win1б використовуються окремі черги повідомлень. Таким чином, додатки win16 фактично ізольовані від інших процесів. Крім того, в Windows 95 застосовані методи очищення і відновлення системи у випадку помилок. Якщо помилка у програмі, що виконується під Windows 3.x, могла запросто "обрушити всю" систему, то помилка в одному з додатків під Windows 95 зазвичай не впливає на виконання інших програм. Низькорівневі компоненти операційної системи ізольовані від прикладних програм, оскільки користуються сервісом іншого рівня захисту мікропроцесора 80386.

Використання пам'яті. Для розробників програмного забезпечення 1ВМ РС довгі роки залишалася каменем спотикання сегментована модель пам'яті 1б-розрядних мікропроцесорів 8088/86 і 80286.

Сегментом є безперервна область пам'яті, що адресується 16-розрядними числами (64 Кбайт). Для того щоб використовувати більш б4 Кбайт пам'яті, довелося розробити систему адресації пам'яті за допомогою двох чисел - адреси початку сегменту і 1б-розрядного зсуву усередині сегмента. Мікропроцесори 80386, здатні оперувати 32-розрядними адресами, могли б без всяких премудростей (і забирають час обчислень!) Адресувати до 4 Гбайт, оперативної пам'яті, Але МS-DOS і Windows 3.x вимушено продовжували використовувати застарілу сегментовану модель пам'яті.

Для win32-додатків доступна плоска (несегментірованное) модель пам'яті Windows 95. Система повністю використовує адресованих пам'ять 38б-х процесорів, при цьому прикладні програми можуть працювати з об'ємом пам'яті до 2 Гбайт, інші 2 Гбайт Windows 95 використовує для власних потреб. Файл віртуальної пам'яті Windows 95 має динамічний розмір, обмежений тільки об'ємом жорсткого диска і не залежить від фрагментації.

Використання системних ресурсів. Під системними ресурсами в термінології Windows розуміють області пам'яті, що використовуються модулями USER і GDI. У ресурсах GDI розташовується інформація про графічних об'єктах, що використовуються системою в даний момент. Ресурси USER включають інформацію про вікна, меню і так далі. Для того щоб максимально прискорити процедуру звернення до ресурсів USER і GDI, в Windows 3.x їх обсяги обмежили сегментами по б4 Кбайт. Кожне породжене системою вікно забирало приблизно 2% системних ресурсів, а коли відсоток вільних системних ресурсів падав до 20%, завантаження нових програм ставала неможливою.

Більша частина ресурсів Windows 95 зберігається в областях пам'яті з 32-розрядної адресацією, Відповідно обсяг ресурсів Windows 95 практично необмежений. Ті з старих Windows-програм, які безпосередньо звертаються до системних ресурсів, можуть використовувати їх під Windows 95 так само, як і раніше.

Файлова система. Одне з найбільш настирливих обмежень систем МS-DOS і Windows 3.x - імена файлів, які складаються не більш ніж з 11 (8 +3) символів. Нова файлова система дозволяє win32-додаткам користуватися довгими (до 255 символів) іменами файлів і при цьому залишається повністю сумісною з FAT. Зрозуміло, користуватися такими іменами файлів набагато зручніше.

Деякі компоненти нової файлової системи були використані ще в Windows 3.11 для робочих груп - драйвер встановлюються файлових систем, 32-розрядний драйвер FАТ, 32-розрядне кешування жорсткого диска. Всі ці риси отримали подальший розвиток у Windows 95. Крім того, з'явилися 32-розрядний драйвер CD-ROM, більш потужна підсистема блокового вводу-виводу і інші риси.

Підтримка драйверів пристроїв. Аиболее громіздкі МS-DOS драйвери, що займали найбільше місця в базовій пам'яті або UMB, тепер не потрібні при використанні оболонки захищеного режиму. Згідно документації Microsoft система Windows 95 забезпечує:

повну підтримку розділення доступу до файлів, замінюючи резидентну програму SНАRЕ.ЕХЕ;

повну підтримку різноманітних звукових плат, СD-ROM приводів та інших мультимедіа-пристроїв, не вимагаючи при цьому установки МS-DOS драйверів;

підтримку файлової системи СD-RОМ дисків, замінюючи MSCDЕХ.ЕХЕ;

кешування дисків, замінюючи SMARTDrive;

роботу з мишею не тільки в графічному середовищі, але і з MS-DOS-програмами, замінюючи драйвер миші для MS-DOS;

динамічне стискування даних, замінюючи DRVSpace.BIN (DBLSPACE.BIN);

повну підтримку роботи станції в локальних мережах MS-NЕТ і Novell Netware, замінюючи все резидентні програми, які доводилося завантажувати для роботи в цих мережах.

Windows 95 підтримує поточну версію протоколу Plug-and-Play. При установці додаткового пристрою, що підключається на основі Plug-and-Play, система сама піклується про його конфігуруванні.

Досить зручно використовувати Windows 95 і без апаратної підтримки Plug-and-Play - система надзвичайно багато знає про те, які існують зовнішні пристрої і як ідентифікувати, включаючи СD дисководи, звукові карти модеми, миші та багато іншого.

Графічна оболонка Windows 95. Інтерфейс Windows 95 відповідає вимогам самих вимогливих користувачів, дизайнерів і фахівців з ергономіки. На мій погляд, інтерфейс Windows 95 неперевершений, і перейти на цю систему варто було б навіть у тому випадку, якщо б новим у ній був тільки інтерфейс.

Сучасний користувальницький інтерфейс. Вигляд оболонки Explorer, заснований на повноцінному втіленні метафори робочого столу і папок, зручний і наочний. Панель завдань дає повний огляд програм, виконуваних системою в даний момент. Доступ до всіх об'єктів, будь то програми, документи, мережеві ресурси або інструменти налаштування системи, уніфікований. Імена будь-яких об'єктів можуть містити до 255 символів.

Багатий сервіс. Оболонка Windows 95 надає користувачеві багатий і різноманітний вибір робочих інструментів. Як приклад назву можливість створення так званих ярликів для швидкого доступу до необхідних додатків і документів, дуже вдале засіб пошуку документів і вбудовану програму швидкого перегляду документів різних форматів. Виконання багатьох дій, включаючи установку апаратних компонентів, відправку поштових та факсимільних повідомлень, встановлення зв'язку між комп'ютерами, автоматизовано за допомогою спеціальних програм-майстрів.

Широкі можливості налаштування. Windows 95 можна налаштувати сотнями способів, причому доступ до засобів налаштування користування ними дуже прості.

Зручність роботи з документами. Windows 95 - це наступний крок до інтеграції різних прикладних програм одну робочу середу. Можна легко створювати документи засобами оболонки, переносити дані з документа на робочий стіл і в інший документ, викидати в "сміттєвий кошик" фрагменти тексту, документи або цілі папки, а при необхідності - повертати їх.

Удосконалена довідкова система. Довідкова система Windows стала зручніше і гнучкіше. Багато розділів довідки складені у вигляді покрокових інструкцій з можливістю виконання тих чи інших дій, які рекомендуються безпосередньо із системи допомоги.

"Емуляція" MS-DOS.MS-DOS 7.0 + Windows 4.0. Покинути оболонку Windows 95 для роботи з МS-DOS програмами в реальному режимі можна, тільки ініціювавши перезавантаження або вимкнення системи або ж перейшовши в режим емуляції МS-DОS (МS-DOS mode) з можливістю повернення в графічну оболонку по команді ЕХIТ. Схоже, що нормальним станом Windows 95 дійсно є графічний інтерфейс, який завжди знаходиться десь під рукою, в пам'яті комп'ютера. Але це не так.

У дійсності "режим емуляції МS-DOS" представляє собою класичну МS-DOS, працює в реальному режимі і адресують 640 Кбайт оперативної пам'яті. Графічна система Windows 95 з усіма своїми перевагами як і раніше є оболонкою захищеного режиму для MS-DOS. Навіть новітні 32-розрядні графічні додатки для Windows 95 продовжують використовувати для виконання окремих операцій функції МS-DOS і базову область пам'яті.

Таким чином, визначення Microsoft Windows 95 як операційної системи, що не вимагає окремої копії МS-DOS, засноване на тому, що Windows 95 включає в себе все, що їй потрібно від МS-DOS. Ніщо краще МS-DOS не підтримає MS-DOS-додатки, саме в МS-DOS найкраще почувають себе ті 16-розрядні драйвери пристроїв, які все-таки доводиться завантажувати (наприклад, драйвери сканерів).

При цьому весь комплекс зроблений так, що звичайному користувачеві начебто й нема чого щось знати про МS-DOS, а кваліфікований користувач, навпаки, зможе застосовувати як нові, так і старі, випробувані методи роботи з системою.

1.2. Аналіз механізму скріплення і впровадження

Науково-технічний прогрес 90-х років обумовив неухильне зростання популярності об'єктно-орієнтованого програмування (ООП), і в даний час багато програмісти перейшли у своїй роботі на С + + або Visual Basic. Вже існують об'єктно-орієнтовані бази даних, об'єктно-орієнтовані дизайн та аналіз і навіть об'єктно-орієнтована СОВОL. На природно виникає питання - чи не залишилися Windows або операційні системи в об'єктно-орієнтованому відношенні далеко позаду. Безумовно, ні. Продукт OLE (Objekt Linking and Embedding) компанії Microsoft відкриває нові шляхи для застосування об'єктів в Windows. ОLE передбачає новий спосіб мислення. Програміст в середовищі ОПП повинен мислити про все як про об'єкти - від файлу на диску, елемента даних або програми до апаратного забезпечення та операційної системи. Крім того, OLE змушує програміста слідувати суворому набору правил, на залежних від мови програмування, операційної системи або навіть від апаратної платформи.

Введення в OLE. OLE служить основою, на якій будуються об'єкти. Ця абревіатура означала спочатку зв'язування та впровадження об'єктів (Objekt Linking and Embedding) з випуском версії ОLE 2 застосування ОLE уже не вкладається в рамках, зв'язування та впровадження. ОLЕ сьогодні включає в себе уніфіковану передачу даних, структуроване сховище інформації та автоматизацію. Не слід звужувати уявлення про ОLЕ скріпленням і впровадженням; дивитися на ОLЕ слід як на набір будівельних блоків, що дозволяють створювати складні додатки. Насправді Microsoft перестала розшифровувати абревіатуру ОLE як Objekt Linking and Embedding, щоб змінити що склалося сприйняття ОLЕ.) / 2 /

Призначення і історія ОLЕ. Якщо до появи OLE 1 у користувача Windows була електронна таблиця, яку йому потрібно було вставити в документ текстового редактора, звичайно він повинен був експортувати дані з таблиці у файл стандартного формату, імпортувати дані з файлу в текстовий редактор, а потім в редакторі їх переформатувати. Якщо користувачеві щастило і обидва додатки підтримували копіювання і вставку, то замість явного експорту / імпорту він міг копіювати інформацію через буфер Clipboard. Кожного разу, коли електронні таблиці змінювалися, процес перенесення даних потрібно було повторювати. Це, природно, призводило до зайвої витрати часу і сил.

Але незадовго до виходу Windows 3.1 з'явилося ОLE 1, і це значно спростило описану використання загальних даних в подібних програмах (якщо вони вміли працювати з ОLЕ). На зміну операціями експорту / імпорту і копіювання прийшли зв'язування та впровадження. Стало можливим так підключити електронну таблицю до текстового редактора, щоб документ редактора відбивав найостанніші зміни, що відбулися в електронній таблиці. Крім того, електронна таблиця (яка з'явилася в текстовому документі) може бути обрана натисканням кнопки миші. При цьому автоматично запускається додаток електронної таблиці, що дозволяє виконувати редагування даних або інші специфічні для таблиць операції. Команда Update закриває електронну таблицю, і оновлена ​​електронна таблиця впроваджується в документ текстового процесора.

OLE 2 є наступним логічним кроком у розвитку цієї стратегії. У ОLE 1 натискання кнопки на електронній таблиці, що знаходиться в документі текстового документа, призводило до запуску програми в окремому вікні. У ОLЕ 2 вводиться поняття активації по місцю (також відоме під назвою візуального редагування). Програма електронної таблиці запускається як і раніше, але замість окремого вікна електронна таблиця як би зливається з текстовим редактором. Змінюється меню, відображаючи меню електронної таблиці. Змінюється навіть інструментальні лінійки, але ви все одно перебуваєте в текстовому редакторі. Два додатки як би поєднуються і текстовий редактор набуває функціональні можливості електронної таблиці. Так користувачеві потреби переключатися для перегляду даних з однієї програми на інше, і ви можете працювати з додатком, який задовольняє більшості ваших потреб, і всередині нього використовувати можливості інших додатків.

Для ОLE 2 довелося переробити заново багато чого з існувало в ОLE 1 щоб розширити його функції та покращити продуктивність. Наприклад, ОLЕ 1 побудовано на динамічному обміні даними (DDЕ). Для передачі інформації туди і назад DDE у своїй основі використовує повідомлення Windows і поворотні виклики. Оскільки використовуються повідомлення Windows, DDЕ обмежується рамками однієї машини. OLE2 не спирається на DDE замість цього воно побудовано на протоколі LPRC (Lightweight Remote Procedure Calls - легких віддалених процедурних виклики).

Архітектура ОLЕ. Щоб досягти своїх задуманих функціональних можливостей, ОLE в якості будівельних блоків використовує велику кількість об'єктів. OLE містить нові об'єкти для реалізації таких концепцій, як Формування (marshaling), яка обслуговує комунікацію між процесами і спирається на LPRC; структуроване сховище, що забезпечує зберігання документів, що містять інші документи; ярлик (moniker), керуючий підключенням і перемиканням пов'язаних даних. Кожен з цих механізмів необхідний ОLE для виконання своєї роботи. Крім того, ОLE вводить поняття автоматизації, яке не потрібно для скріплення і впровадження в традиційному сенсі. Автоматизацію можна розуміти як спосіб, за допомогою якого користувач може працювати з вашим застосуванням всередині певного їм самим макромови. Сервер-автомат OLЕ управляється будь-яким автоматним контролером OLE (див. таблицю).

Додатки-автомати - сервери та контролери.

Продукт	Автоматний сервер	Автоматний контролер
Visual Basic	та	та
Exel	та	та
Word 6.0	та	немає
AutoCad 12LT	та	немає
PhotoShop 3.0	та	немає
CorelDraw 5.0	та	немає

Додатки які одночасно є і серверами і контролерами можуть як управлятися із зовні, так і управляти іншими додатками. У традиційному програмуванні додаток або сервер, або контролер, але не одночасно і те і інше. OLE змушує розлучитися з таким способом мислення і надає розробникові програми право вибору - чи буде його застосування сервером або контролером.

Об'єкти. Під поняття о6ьекта ОLЕ потрапляє все, що може мати машинне подання. Об'єктом може бути документ текстового процесора, малюнок або креслення, також частину креслення (припустимо який або шар креслення друкованої плати), відео-кліп, звук або навіть додаток. Таке розуміння розходиться зі стандартною інтерпретацією, у якій об'єкти - дані, з яких виробляються маніпуляції за допомогою функцій і процедур. Хоча OLE підтримує об'єкти тільки в рамках однієї машини, це не обмеження архітектури OLE, а лише обмеженість її реалізації. Вже демонструвалася версія OLE, названа розподіленим ОLЕ, в якій межі між машинами для об'єктів прозорі. Іншими словами, якщо ваш додаток запитує OLE-об'єкт, то постачальник цього об'єкта не обов'язково знаходиться на вашій машині, хоча з точки зору вашого застосування ОLE-об'єкт - локальний.

Інтерфейси. OLЕ інтерфейс - це механізм, який використовується для доступу до групи пов'язаних з об'єктом функцій. Якщо ви хочете виконати в OLE операцію над об'єктом, можна запитати специфічний інтерфейс, що має потрібну вам функцію. Коли ви запитуєте інтерфейс, то звертаєтесь до об'єкта, вказуючи його ID-номер. Кожен інтерфейс має унікальний номер-ідентифікатор (Interface ID або IID). Об'єкт повертає або стан помилки, якщо об'єкт не підтримує запитаний інтерфейс або відбувається інша помилка, або він повертає покажчик на необхідний інтерфейс.

Компонентна модель об'єкта. Компонентна модель об'єкта (також відома під абревіатурою СОМ) - це специфікація, що визначає сполучний ОLЕ клей. СОМ визначає, яким чином об'єкти взаємодіють. СОМ передбачає для об'єктів ОLЕ таку специфіку, зокрема диктуючи, які інтерфейси об'єкту необхідні, як об'єкт може бути створений і коли він може бути знищений.

Структуроване сховище. Структуроване сховище - це специфікація, що визначає метод зберігання об'єктів. Структуроване сховище можна уявити собі як OLE-аналог DOS. Цей механізм підтримує більшість з функцій DOS - файли і каталоги, копіювання і переміщення файлів (файли називаються потоками, а каталоги - сховищами. Крім того, термін "структуроване сховище" інформації не має на увазі, що дані зберігаються на диску. Так само як і файли DOS , що можуть перебувати на RAM-диску, жорсткому диску, флоппі-диску або навіть на CD-ROM, об'єкти, розміщені в структурованому сховищі, можуть перебувати в будь-якому з цих місць, а також і в інших. Щоб DOS могла використовувати для зберігання інформації інші пристрої, такі, як оптичний флоппі-диск або мережевий диск, звичайно потрібний драйвер пристрою. Структуроване сховище інформації також має методи для підтримки нестандартних пристроїв.

Складовою документ є спеціальним випадком структурованого сховища, призначеного для зберігання наборів об'єктів в додатках-контейнерах (контейнерні додатки - це програми які використовують і зберігають об'єкти).

Автоматизація. OLE-автоматизація - це нагляд інтерфейсів, у типовому випадку псзволяющій використовувати додаток як ОLЕ об'єкта. Автоматизація можлива не тільки для додатків у формі виконуваних модулів (ЕХЕ), але і для динамічно приєднуваних бібліотек (DLL). Автоматизація дозволяє за допомогою набору певних правил ззовні запрограмувати або спеціалізувати програму. Це дає додатком, наприклад, Visual Basic, можливість управляти Exel, в результаті чого функції Ехсеl стають доступні вашому додатку на Visual Basic. Автоматний контролер OLE управляє об'єктами-автоматами за посередництвом автоматного сервера.

Уніфікована передача даних. Уніфікована передача даних - це набір інтерфейсів, які дозволяють клієнту і серверу обмінюватися даними. Вона є DDE-еквівалентом і функцій буфера cut / сміттю / paste, зібраних воєдино. Уніфікована передача даних надсилає повідомлення в випадок якщо дані змінюються (подібно зв'язку DDE), а також підтримує переговори про формат, в якому дані будуть передаватися. Крім того, уніфікована передача даних передбачає можливість передачі одного лише дескриптора (handle) даних замість самих даних. Об'єкт-сервер може вирішити, що замість передачі 20 Мбайт даних в оперативну пам'ять через буфер обміну об'єкту-клієнту буде переданий дескриптор даних, щоб клієнт сам міг їх одержати. Це позбавляє сервер від необхідності читання всіх даних і передачі їх клієнту, а клієнта від необхідності самостійного опрацювання даних. Це також позбавляє кінцевого користувача від сидіння перед екраном комп'ютера в очікуванні закінчення обміну.

Зв'язування та впровадження (Linking and Embedding). Зв'язування та впровадження - два принципи, які за традицією відомі в OLE (Objekt Linking and Embedding) краще за все. Зв'язування та впровадження (замість цього тепер говорять просто про документи ОLЕ) дозволяють об'єкту-клієнта (який може бути іншим додатком) прикріпитися до об'єкта-сервера. Приєднання може або здійснюватися зв'язуванням (дані знаходяться поза складеного документа), або дані можуть впроваджуватися всередину складеного документа. Впроваджені дані зберігаються безпосередньо в документі, в той час як при зв'язуванні для доступу до даних OLE в дійсності зберігає свого роду дорожню карту. Дорожньої карта називається ярликом (moniker). Коли ОLЕ отримує запит на відновлення даних, воно дивиться на ярлик (дорожню карту), щоб їх відшукати. Пов'язані дані можуть зберігатися в не належить ОLЕ файлі або в структурованому сховищі (можливо навіть, що дані знаходяться де-то в самому складеному документі).

Складовою частиною зв'язування та впровадження є здатність OLE виконувати активацію за місцем. У OLE 1 при подвійному натисканні кнопки миші над пов'язаним або впровадженим об'єктом запускається сервер цього об'єкта. У ОLЕ 2 можлива активація за місцем. Для користувача два додатки є як би одним. Активація за місцем приєднує потрібні частини програми сервера (такі, як пункти меню та інструментальні лінійки) до додатка клієнта, коли користувач працює з впровадженим об'єктом. При подвійному натисканні кнопкою миші над впровадженим об'єктом відбувається перетворення додатку клієнта, в ньому змінюються меню та лінійки інструментів, а також інші елементи інтерфейсу, для роботи з додатком сервера впровадженого об'єкта. При подвійному натисканні кнопкою миші над пов'язаним об'єктом додаток сервер запускається в окремому вікні (як в OLE 1).

У термінах OLE описане вище дію (подвійне натискання для активації сервера) називається активацією ззовні (outside-in). При активації ззовні сервер об'єкта не активується (не запускається), поки користувач не натисне над об'єктом кнопку миші двічі. Активація зсередини (inside-out) вимагає, щоб об'єкт-клієнт активував об'єкт-сервер завжди, коли об'єкт-сервер видно. Сервер приймає управління по однократному натисканні кнопки миші - тому, що для активуються зсередини об'єктів він вже запущений заздалегідь.

Як можна бачити, архітектура ОLE досить багата, а зв'язування та впровадження - лише частина загальної структури.

1.3. Вибір і обгрунтування мови програмування

Сьогодні у зв'язку з усе більш прискорюваними технологіями програмування, постійно підвищуються вимоги до середовища і до самої мови програмування. Найбільш злободенні вимоги можна описати таким чином.

1. Відділення елементів програми, пов'язаних з призначеним для користувача інтерфейсом від алгоритмічної частини. Це дозволяє мінімізувати або взагалі уникнути при правильному проектуванні проекту змін до алгоритмічної частини проекту при модернізації користувальницького інтерфейсу незалежно від причин їх викликають: вимога замовника проекту по заміні невірної написи або кардинальної зміни концепції внаслідок перекладу розробок на іншу платформу.

2. Простота і швидкість створення / модернізації користувальницького інтерфейсу і самих програм, шляхом використання вже готових елементів (блоків), які реалізують якісь великі функції взаємодії з людиною або іншою програмою.

3. Ще раз простота, а також ясність і наочність при програмуванні користувальницького інтерфейсу, що приховує нижній, складний шар і залишає на поверхні тільки малу, але самодостатню необхідну частину айсберга управління елементами інтерфейсу.

4. Використання вже існуючого коду, можливо, написаного на іншій мові програмування.

При розробці додатків для Windows вищевикладеним принципам дуже вдало відповідає Visual Basic. Основні властивості цієї мови програмування наведені нижче.

Можливості Visual Basic.

1. Всі елементи призначеного для користувача інтерфейсу можна створювати / модернізувати / видаляти без жодного зв'язку з алгоритмічної "невидимої" частиною програми. Все, що пов'язане із взаємодією з людиною або іншим суб'єктом управління, знаходиться у файлах форм (FRМ), VВХ і ОСГ, а все, що пов'язано з розрахунковою частиною, - у файлах стандартних модулів (ВА) і класів (СLS), або, якщо потрібна швидкість обробки - у спеціально написаних на С, Pascal, Fortran або інших мова програмування, DLL. Але це рознесення насправді чисто умовно і робиться просто з метою полегшення роботи самому розробнику або, що більш важливо, - групі розробників. Насправді, при недбалому проектуванні або невеликий поставленому завданню і інтерфейсна і алгоритмічна частина можуть розташовуватися в одному модулі (FRМ або ВА).

2. Формування користувальницького інтерфейсу в Visual Basic схоже на роботу з дитячим конструктором - всі елементи на увазі, всі елементи прості, але складність створюваної конструкції обмежена тільки винахідливістю розробника. Причому треба мати на увазі, що кількість елементів цього конструктора постійно і дуже швидко зростає. Сотні (на початок 1995 року близько тисячі) сторонніх виробників і фірм постійно викидають на ринок все нові, більш потужні моделі розширення для Visual Basic.

3. Якщо вже є готовий алгоритм ШПФ (Швидкого Перетворення Фур'є) на асемблері або алгоритм швидкого пошуку в відсортованому списку на С або Pascal, не треба переписувати їх на Visual Basic. Досить оформити їх вигляді DLL і використовувати як функції.

4. Можна за допомогою Visual Basic для Windows створювати запускаються ". EXЕ" файли. Visual Basic для Windows створює виконуються (". ЕХЕ") файли, але не самодостатні. Усі програми, створені на Visual Basic, повинні розповсюджуватися з файлом VBRUNx00.DLL (x - номер версії 1,2 або 3) або VB400xx.DLL (xx - 16 або 32). Ця DLL обов'язково має бути присутня у кожній системі, де використовуються програми на Visual Basic для Windows.

Visual Basic дає можливість створювати додатки, що працюють середовищі Windows. Програми компілюються в псевдокод (р-коді) і поміщаються у файли з розширенням ". ЕХЕ". Коли програма запускається, файл з р-соdе звертається до VBxxxx.DLL, яка інтерпретує р-code у послідовність інструкцій Windows АРI.

5. Використання функцій Windows АРI в Visual Basic досить просто - необхідно її оголосити (declare) в секції оголошень або модулі коду.

Windows АРI - набір DLL, що містять функцій загального призначення середовища Windows. Доступ до функцій АРI дозволяє виконати безліч речей, включаючи відображення меню, маніпуляції із зображеннями, програш музичного фрагмента і т.д.

6. Використовуваний механізм додавання елементів керування VВХ (Visual Basic eXtension - модулі розширення Visual Basic) явив собою "чорний хід" для розробників третіх фірм по впровадженню власних об'єктів в середовище розробки Visual Basic. Механізм, нехай і не об'єктно-орієнтована, але дозволяє просто і досить елегантним шляхом додавати нові програмні компоненти без додаткового програмування. Механізм VВХ є специфічним інтерфейсом для Visual Basic.

7. Існує відкритий стандартний інтерфейс для роботи з програмними компонентами, в кожну програму і додаток можна інтегрувати стандартний набір засобів, що дозволяє використовувати в подальшому дані програми у вигляді компонент для майбутніх додатків. Механізм ОLЕ і нова технологія у вигляді ОСГ (ОLЕ Custom Control). ОLЕ не тільки пропонує стандарт у визначенні об'єкта, але також визначає, як і яким чином об'єкти можуть взаємодіяти один з одним. / 3 /

Основні нововведення в Visual Basic версії 4.0

наявність 16 - і 32-розрядної редакції;

робота в середовищі Windows 3.1, Windows для Робочих Груп 3.11, Windows 95, Windows NТ;

можливість створення ОLЕ Automation об'єктів;

підтримка OСХ і VВХ;

розширення ТооlВох (Вікно інструментарію) за рахунок ОLЕ Insertable об'єктів;

використання JЕТ версії 2.5;

наявність нових і підтримка спеціалізованих Data Bound Control (об'єктів, що значно спрощують роботу з базами даних);

використання ВАО версії 2.0;

відкрита і розширювана середовище розробки;

можливість розбиття довгих рядків у програмному коді;

розширення лексики мови програмування;

запуск одночасно декількох копій Visual Basic 4.0;

директиви умовної компіляції;

підтримка файлів-ресурсів;

створення 32-розрядних додатків;

Директиви умовної компіляції програми. Розробник має можливість, використовуючи директиви умовної компіляції вибирати, наприклад, яку версію програми (16 - або 32-розрядну) він збирається створити. Використовуючи подібні директиви, можна створювати програми, що мають один і той же вихідний текст, але які після компіляції зможуть працювати на різних платформах.

Object Browser (Інспектор об'єктів). Дане засіб призначений для полегшення ідентифікації та керування всіма ОLЕ Automation Servers, на які є посилання в проекті. Вибравши потрібний об'єкт, розробник може легко вибрати і передати коректний синтаксис виразу роботи з об'єктом в текст програми або викликати вбудовану допомогу для даного об'єкта.

Вбудований редактор. Збільшено функціональні міць вбудованого редактора. По-перше, розширені можливості настройки, точніше споруди, "на свій смак" формату відображуваних рядків коду, коментарів, ключових слів, ідентифікаторів, точок зупинки, і т. д. Можна задати різні фонт, кольору і розміри фонтів для полегшення читання тексту програми . По-друге, покращена робота з налагодження вікном. Більше немає необхідності тримати і вікно з відладжується текстом програми і вікно з відображеними змінними - тепер достатньо використовувати одне вікно, яке складається з двох рухомих частин: нижня шибка являє собою повнофункціональний редактор коду, верхнє ж показує вміст змінних.

Розширення лексики мови програмування. Для оголошення підпрограм і функцій, доступних або не доступних з інших модулів проекту, введені додаткові службові слова при оголошенні процедур: Public і Private відповідно. Visual Basic 4.0 "прихопив" тепер шматочок Pascal, додавши до свого лексичному запасу виразу "With", "For Each", а також додані нові типи даних - Byte (просте без знакова, для представлення чисел в діапазоні 0-255), Вооlean 16 бітові (2-байта) числа, які можуть приймати тільки два значення: True або False) і Collection. Collection дозволяє побудувати власну групу пронумерованих об'єктів. Використання Collection більш переважно, ніж використання масивів внаслідок більшої гнучкості індексів, і наявності успадкованих методів для вставляються і видаляються об'єктів колекції.

Процедури властивостей (property procedures). З'явилася можливість створювати для об'єктів (форм, стандартних модулів і модулів класів) власні спеціалізовані властивості (properties), і прив'язувати до них виконуваний код, який буде викликатися при зверненні до властивості.

Розширюваність оболонки програмування. Оболонка розробки (IDE) самого Visual Basic 4.0 також може бути керованим через ОLЕ Automation, що дозволяє ОLЕ додаткам створювати і розміщувати в спеціальне меню Add-In Visual Basic 4.0 свої команди, розширюючи таким чином можливості IDE.

Створення ОLЕ Objekt додатків і класи (Сlasses). Однією з основних претензій до Visual Basic з боку професійних програмістів служило відсутність засобів створення готових модулів для подальшого використання. Програміст змушений був звертатися до С, С + +, Раsсаl або інших мов програмування для створення DLL і викликам функцій DLL з програми на Visual Basic або, наприклад, з програми Microsoft Office. З виходом Visual Basic 4.0 дана ситуація корінним чином змінилася, програмісти можуть створити об'єкти ОLЕ Automation. Бібліотеки подібних об'єктів, кожен зі своїми характеристиками і методами управління, можуть бути використані з будь-якої програми, що має можливість контролювати додаток, що є ОLЕ об'єктом (OLE Object Application).

За визначенням, такі об'єкти названі класами (Claases) - (цю частину мови Visual Basic взяв від С + +) і розташовуються в спеціальних модулях (class module). Для сумісності з програмами, реалізованими в третій версії і використовують VВХ зі стандартного набору, Visual Basic 4.0 включає ОLЕ Custom Control (OCX), які замінять ці VВХ. При виклику проекту програми, розробленої в середовищі попередньої версії Visual Basic і використовує один із стандартних VBX запропонує автоматично перетворити посилання на нові ОСГ. Такі програми, як Microsoft Excel для Windows, Microsoft Word для Windows і інші, що є ОLЕ додатками, тепер можна вставляти в Вікно інструментарію (ТооlBох) як звичайні елементи управління.

Таким чином можна сказати про певну універсальність Visual Basic для створення додатків для Windows.

2. РОЗРОБКА структурну схему та алгоритм ПРОГРАМИ

2.1. Функціональна схема роботи Windows 95

Операційна система повинна забезпечувати взаємодію програми як самої верхньої ступені з самим нижнім рівнем ієрархії - апаратною частиною комп'ютера, через набір будь-яких стандартних функцій і підпрограм. Крім того вона повинна забезпечувати користувача зручним інтерфейсом. Розглянемо як це реалізовано в обраній операційній системі Windows 95. Функціональна схема роботи операційної системи Windows 95 представлена ​​на рис 2.1.

Апаратна частина комп'ютера представляє собою будь-які пристрої введення-виведення інформації (клавіатура, миша, принтер, плоттер, сканер, пристрій читання компакт дисків, монітор і т.д.) підключена на системну шину через так звані контролери пристроїв мають в адресному просторі пам'яті обчислювальної машини якісь адреси звані портами введення-виведення. Через ці порти при низькорівневого програмування програміст може обмінюватися інформацією з пристроєм. Але зараз така технологія вважається застарілою і приводить до зайвих витрат ресурсів. Адже в такому разі стандартні функції обміну інформацією повинні знаходиться в кожній програмі яка могла обмінюватися інформацією з зовнішніми пристроями.

Windows 95 забезпечує взаємодію із зовнішніми пристроями як з потоками інформації незалежно від самого пристрою через свої власні драйвера пристроїв.

Отже, пристрої обміну інформацією підключаються до комп'ютера через контролери, якими управляють драйвери пристроїв. Драйвери пристроїв розроблені таким чином, що при передачі інформації на пристрій вони організовують чергу дотримуючись якої на пристрій передається інформація від різних додатків (наприклад принтер). Однак при передачі інформації в зворотному напрямку (від пристрою) драйвери створюють так звані події (наприклад подія "закінчено друк" від принтера або "натиснута кнопка" від миші), які операційною системою поміщаються в глобальну чергу подій, з якої події потрапляють в спеціальний блок визначення призначення події. Там за інформацією зберігається в системі: пріоритет події, яка програма відкрило потік обміни з пристроєм, пріоритет програми відкрив потік обміну та ін Визначається призначення події, його приналежність певній віртуальній машині організованою системою. За цим призначенням передається повідомлення про те, що відбувається подію додатком яке повинно його обробити.

В окремій віртуальній машині додатки по приході подій організовується локальна чергу подій. З якої повідомлення про події передаються по так званому фокусу об'єкту який у цей момент перебуває у фокусі. Об'єктом може бути будь-який елемент управління (як то кнопки, поля введення, іміджі, іконки, картинки і т.д.). З об'єктом пов'язана ціла система процедур і функцій які можуть обробляти події приходять об'єкту, а також можуть передавати їх іншим об'єктам або вище на щабель по ієрархії об'єктів (елементи управління передавати формам, а форми у свою чергу більш глобальним форм або вікнам застосування чи самій системі) .

Таким чином, завдання програміста полягає у створенні підпрограм і функції реагують певним чином на події приходять від системи, для всіх об'єктів які можуть використовувати ці події з метою визначених програмою в цілому, для конкретної задачі поставленої перед програмою.

2.2. Використовувана термінологія

Отже, Visual Basic призначений для швидкого створення додатків в середовищі Windows, і як будь-яка програма для Windows, програма, написана на Visual Basic, повинна мати як мінімум одне вікно.

У термінах Visual Basic всі вікна є форми, у програмі може бути безліч вікон-форм. Форми в програмі служать для відображення елементів призначеного для користувача інтерфейсу. На кожній формі може знаходиться певна кількість елементів управління, а також графіка і навіть інші форми, причому, як вироджений випадок, на формі може взагалі не розташовуватися жодного елемента.

У тому випадку, коли додаток використовує вікно-форму для відображення різних типів інформації або надає можливість працювати в декількох режимах, щоб не засмічувати площа вікна безліч додаткових елементів, використовується лінійка спадаючих меню. Кожне меню містить список пунктів, які в свою чергу можуть розгортатися в підменю. Назви подібних вкладених підменю, а також пунктів меню, при виборі яких потрібно в окремому діалоговому вікні виконати якісь додаткові дії, при відображенні у списку пунктів меню доповнюються справа трьома крапками.

Елементи управління служать для відображення інформації, вибору з деякої безлічі об'єктів, а також для більш ясного і чіткого сприйняття.

Будь-яка, навіть найпростіша програма на Visual Basic, має свій Проект (project), інформацію про який зберігається в спеціальному файлі. У проект програми, який відображається в спеціальному вікні Проекту, містяться всі форми, модулі та файли, сукупність яких і складає програму.

Visual Basic не є об'єктно-орієнтованою мовою в догматичному розумінні ООП (об'єктно-орієнтоване програмування), Visual Basic базується на парадигмі подієво-орієнтованого програмування: програма - суть якийсь набір реального або віртуального світу, кожен з яких розуміє якийсь обмежений набір подій (можлива, розширюваний). По приходу кожної події з набору відслідковуються подій форми і елементи управління можуть реагувати певним чином, відповідно до програмним кодом, реалізованим програмістом для кожного об'єкта.

Для внесення керуючого програмного коду для подій і методів використовується Редактор Коду, який служить для створення, перегляду і модифікації підпрограм (Sub) і функцій (Function). Процедура представляє собою підпрограму, яка не повертає результату.

Програмний код, пов'язаний з формами та елементами управління, служить для реалізації відповідної реакції програми на дії користувача або прихід системного події.

Програмний код може знаходитися в спеціальних програмних модулях (стандартні модулі та модулі класів) або бути "прив'язаний" тільки до елементу управління (тобто об'єкта) або формі.

Крім набору подій (events), для кожного елемента управління існує зумовлений (можливо, розширюваний) набір властивостей або характеристик (properties), що представляють собою деякі початкові установки. Дані властивості поділяються по сфері доступності: є властивості, які можуть встановлюватися тільки в режимі розробки, тільки під час виконання програми або в обох випадках. Установка та налаштування властивостей об'єктів здійснюється у вікні Властивостей (Properties).

Для елементів керування та форм також існує пов'язаний з ними набір методів (method), які можна розглядати як набір команд, що розуміються даним об'єктом.

Для деяких відображаються на екрані елементів управління є можливість задавати різні основні кольори та кольори фону. Для зручності вибору потрібних кольорів використовується Колірна Палітра (Color Palette).

2.3. Синтез загальної структурної схеми програми

Таким чином переходячи до синтезу структурної схеми програми можна умовно розбити на кілька логічних блоків. Кожен з яких представляє собою набір прив'язаних до об'єктів підпрограм, функцій і даних (рис. 2.2).

Основною ланкою програми є головна форма програми (Main_Form.frm) представляє собою головну інтерфейсну частину програми. У якій відбуваються всі перетворення проекту. Проектом, в контексті даної програми, називається сукупність документів і функцій OLE Automation знаходяться в робочій області програми в певному взаємодії один з одним. Над якими можуть проводиться визначення дії по створенню, редагуванню, видаленню, запуску функцій і пр. що призводять до зміни як самого проекту в цілому, так і просто документів входять в проект.

У головній формі містяться коди з обробки всіх меню містяться в програмі, в тому числі і функцій роботи з системним буфером обміну інформацією. Крім того головна форма містить програмний код обробляє всі зміни проекту з точки зору користувача. У тому числі створення документів, функцій, їх переміщення в проекті, видалення запуск функцій на обробку документів та ін

З головної форми проводиться активізація всіх дочірніх форм програми в режимі модальних вікон. Тобто вікон до закриття яких робота основної програми головної форми (а іноді і всієї системи в цілому, як наприклад у випадку відкриття вікна повідомлення про глобальну помилку можливо приводить до руйнування системи) призупиняється.

Дочірніми формами по відношенню до головної формі є, форма створення і редагування властивостей документів (MakeDocForm.frm), форма створення і редагування властивостей функцій OLE Automation (MakeFunkForm.frm), форма створення і зміни реєстраційних даних додатків підтримують OLE Automation або для яких необхідна емуляція цієї підтримки (MakeDocForm.frm).

Форма створення і редагування властивостей документів містить всі необхідні елементи управління (об'єкти) для введення та зміни даних про документ, а також його візуальному представленні в проекті (тобто його іконки). Також в цій формі міститься програмний код обробляє ці елементи управління та вносить зміни в глобальну структуру даних щодо документів у проекті. Ця форма являє собою вікно під назвою "Властивості документа".

Форма створення і зміни реєстраційних даних додатків також являє собою вікно під назвою "Реєстратор додатків" і також містить у собі ряд об'єктів (елементів управління) і програмний код обробляє ці елементи керування для зміни даних про зареєстровані додатках які можуть брати участь у проекті в якості безпосередніх обробниках документів, а також у вигляді функції OLE Automation.

Форма створення і редагування властивостей функцій OLE Automation являє собою вікно "Властивості функції" і містить елементи управління дозволяють редагувати властивості функції OLE Automation. Форма також містить програмний код модифікує глобальні дані про функції в проекті.

Всі глобальні дані, а також підпрограми необхідні для роботи більшості блоків програми і не входять у яку або форму містяться в спеціальному модулі (MainModule), який не містить у собі ніяких об'єктів і взагалі візуально не визначається. Він включає в себе тільки програмний код визначає всю структуру даних і зберігає в собі дані про реєстрації додатків, властивостей функцій і документів. А також дані необхідні для нормальної роботи програми в цілому. Як щось, різні змінні за засобом яких проводиться обмін даними між різними формами і вікнами всередині самої програми. А також модуль включає в себе підпрограми і функції необхідні для всього проекту в цілому. Наприклад функції відкриття проекту, збереження проекту на носії інформації і т.д., які не входять в яку-небудь форму і можуть викликатися з будь-якої частини програми.

Наступним логічним блоком програми є блок обробки помилок. Він строго кажучи, не виділяється в у програмному вигляді як окрема частина програми, але він міститься практично в кожній програмної одиниці будь то підпрограма або функція. Однак як суттєва частина всього програмного комплексу його варто відзначити окремим блоком.

Крім форм і модуля в структуру програми входить основний блок програмного коду забезпечує взаємодію з механізмом OLE Automation операційної системи Windows 95. Як раз в цьому блоці здійснюється виконання функцій OLE Automation, на нього лягла основна частина формування повідомлень для Windows та програм, а також розшифровка відповідних повідомлень системи та програм.

2.4. Розробка структурної схеми взаємодії програми з механізмом зв'язування та впровадження

Для більш якісної розробки алгоритму взаємодії програми з механізмом зв'язування і впровадження об'єктів Windows 95, необхідно розглянути функціональну схему роботи OLE і системи OLE Automation (рис 2.3).

У загальному вигляді структура взаємодії операційної системи і додатків складається з трьох частин:

OLE Server - OLE сервер це програма забезпечує деяку кількість функцій

OLE Client (Controller) - OLE клієнт (контролер) є додатком яке користується функціями OLE Automation OLE клієнта

Windows 95/NT є посередником між клієнтами і серверами OLE забезпечуючи їх взаємодія через ряд стандартних потоків і буферів обміну інформацією OLE.

OLE сервер, вірніше його частина відповідає за OLE взаємодія складається з двох частин. Реєстратора інтерфейсів OLE що знаходяться в ядрі, і власне ядра OLE сервера, яке у свою чергу складається з OLE інтерфейсів забезпечують при зверненні до конкретного інтерфейсу ряд опцій званих методами, вони то і є насправді OLE Automation функціями. OLE сервер є незважаючи на простоту описи найбільш складною частиною всього взаємодії посредствам OLE, з точки зору програміста. Ця складність зумовлена ​​безпосередньо складністю самих методів OLE, що забезпечуються сервером.

Windows 95 будучи посередником у всіх операціях між клієнтом і сервером, виконує координуючу роль адміністратора при передачі даних. А також саме Windows зберігає інформацію про всіх інтерфейсах серверів, тут існує структуроване сховище для цих цілей. Також Windows виконує реєстрацію цих інтерфейсів і відповідає на запити IID від клієнтів. Крім того Windows містить буфер обміну інформацією між клієнтом і сервером. Блок OLE Automation виробляє безпосереднє з'єднання сервера і клієнта і забезпечує їх взаємодію.

Дані можуть передаватися через буфер обміну Widows, а також безпосередньо між методами і об'єктом, але цей спосіб вважається не коректним оскільки не дозволяє переміщати OLE об'єкт.

OLE клієнт (контролер) повинен, крім природно викликів самих методів OLE, забезпечувати коректну обробку всіх повідомлень у зворотному напрямку (від сервера), Клієнт складається з трьох взаємопов'язаних частин: блок запиту IID для інтерфейсу об'єкта, блок обробки ОLE документа і самого OLE об'єкта. Перша частина виконує тільки підготовчу функцію, вона запитує IID інтерфейс для конкретного об'єкта у Windows 95, отримує цей інтерфейс і передає його далі до другого блоку. У другому блоці проиходит сама обробка документа OLE об'єкта. Саме в цьому блоці обробляються такі події як активація ззовні і активація зсередини. Застосовуючи при цьому відповідні методи обробки цих подій за отриманими від першого блоку інтерфейси. За цим інтерфейсам блок виробляє активізацію методів застосовуючи або вже заздалегідь відому інформацію про параметри методів і відповідної реакції методів на їх активацію, або отриману через інтерфейс цю ж інформацію. Таким чином впливаючи на об'єкт і будучи посередником при передачі інформації між методами сервера і об'єктом.

OLE об'єкт це сам документ поміщається в додаток клієнта. Являє собою самий залежний елемент у всій структурі взаємодії. Він сам ні на що не впливає, проте на нього впливають методи сервера викликаються клієнтом. І насправді включає в себе тільки дані та їх структуру.

Таким же чином як і структура OLE клієнта, повинна виглядати структурна схема тієї частини контролера автоматично пов'язують об'єктів, яка відповідає за взаємодію з механізмом зв'язування та впровадження Windows 95.

Оскільки, по суті, контролер повинен бути клієнтом практично для всіх додатків присутніх в системі, то інформація про OLE інтерфейсах окремих додатків заздалегідь не відома. З цього ця інформація повинна бути зібрана перед впровадженням конкретних об'єктів, тобто в процесі роботи програми. Це вносить свої корективи в конкретну структурну схему взаємодії програми з OLE - додається блок збору і інтерпретації інформації про інтерфейсах додатків (рис 2.4).

Крім того схема повинна включати в себе блок емуляції OLE для додатків не призначених спочатку для OLE взаємодії.

Таким чином проведений синтез структурної схеми взаємодії з механізмом зв'язування та впровадження (OLE).

Розробка структури даних

Приступаючи до розробки структури даних необхідно розділяти дані за критерієм можливості доступу до них. Так дані застосовуються тільки у формі повинні знаходиться в самій формі, а дані доступ до яких відбувається з декількох форм називаються глобальними і зазвичай поміщаються в модуль з застосуванням префікса Public (для можливості доступу до них із зовні).

У цьому розділі буде описано структуру даних з головного модуля програми в якому зберігаються глобальні дані необхідні для всього проекту.

Модуль складається з чотирьох частин (рис. 2 .. 5), три з яких представляють собою структури для представлення в машинному вигляді даних про реєстрованих додатках, про документи знаходяться в проекті і про функції застосовуються в проекті для роботи з документами. У четвертій частині знаходяться дані необхідні для взаємодії між формами, і нормальної роботи контролера в цілому.

Дані про реєстрованих програми складаються з наступних частин:

глобальний номер реєстрації - представляє собою наскрізну нумерацію всіх коли або зареєстрованих додатків не залежне від кількості встановлених і віддалених програм на даний конкретний момент часу;

опис - текст описує роботу програми, складається користувачем;

ім'я файлу - покажчик на запускається файл програми для роботи з ним блоку OLE Automation;

назва програми - власний розширений назва програми визначене для зручності роботи з програмою;

маска файлів - одне або декілька розширень імен файлів документів з якими може працювати зареєстроване додаток.

Дані про документи знаходяться в проекті зберігаються в такій структурі:

глобальний номер документа - представляє собою наскрізну нумерацію всіх коли або створених документів не залежить від кількості створених і видалених документів на даний конкретний момент часу;

опис - текст описує документ, складається користувачем;

ім'я файлу - шлях та ім'я файлу документа;

час створення документа;

назва програми - ім'я програми яке обробляє цей документ (вибирається із зареєстрованих у програмі застосування чи стандартний обробник Windows документа з таким розширенням);

значок - шлях та ім'я іконки для візуального представлення документа у вікні проекту;

підпис - текст під іконкою документа у вікні проекту;

координати документа у вікні проекту;

покажчики на вихідні з документа функції OLE в проекті.

Найбільш об'ємними є дані про функції OLE містяться в проекті, що складаються з наступних змінних:

глобальний номер функції - представляє собою наскрізну нумерацію всіх коли небудь створених функцій не залежать від кількості створених і видалених функцій на даний конкретний момент часу;

опис - текст описує функцію, складається користувачем;

ім'я файлу - шлях та ім'я файлу функції;

час створення функції;

функція автомата - викликаний метод;

назва програми - ім'я програми яке цю функцію (вибирається із зареєстрованих в програмі функцій);

значок - шлях та ім'я іконки для візуального представлення функції у вікні проекту;

підпис - текст під іконкою функції у вікні проекту;

координати функції у вікні проекту;

прапор автоматичного виконання функції в разі зміни будь-якого вхідного в з функцію документа;

прапор запиту користувача перед виконанням функції;

покажчики на вихідні функції OLE в проекті;

покажчики на вхідні функції OLE в проекті;

покажчики на вихідні з функції документи;

покажчики на вхідні у функцію документи;

лінковщік документів і функції - рядок зв'язує документи і функцію в один рядок використовувану програмою як виклик функції з параметрами.

Четверта загальна частина складається з різних змінних необхідних для роботи всієї програми складається з наступного:

різні прапори встановлювані і знімаються різними функціями і підпрограмами для поділу ресурсів виділених програмі;

глобальні змінні визначають кількість документів, функцій OLE і зареєстрованих додатків на даний момент часу;

змінні обміну інформації (що визначають стан буфера обміну і структуру даних що знаходяться в буфері обміну).

Таким чином визначені всі дані, необхідні для роботи всієї програми в цілому. Крім того в кожній окремій формі існує область оголошення змінних, в якій визначаються змінні для роботи конкретно цієї форми.

Існують також і області оголошень змінних в кожній окремій функції і підпрограмі для роботи цієї функції. Такий поділ областей видимості дозволяє більш гнучко управляти даними в програмі.

Інструкція користувача по роботі з програмою

Перед запуском програми контролера програму необхідно інсталювати її на жорсткий диск. Це може виконати як спеціальна програма інсталяції, так і сам користувач. Потрібно встановити саму програму в спеціальну директорію, а спеціальні DLL-файли додати в директорію з системою Windows. Процес це складний для користувача-початківця. За цим рекомендується довірити його програмі інсталяції.

Після установки програми на диск її можна запускати, для цього потрібна лише двічі клацнути на іконці програми або в головному меню Windows ("Пуск") вибрати пункт "Виконати" і змінити шлях до виконуваного файлу до запускається файлу контролера - Controller.exe і натиснути кнопку "ОК". Після чого програма запуститься і на екрані з'явиться головна форма програми (вікно).

Інтерфейс програми дозволяє, знаючи загальні принципи побудови інтерфейсу в системі Windows 95, без особливих зусиль навчиться користуватися програмою. Крім того контекстна допомога і використання стандартних клавішних комбінацій для стандартних операцій застосовуються у системі набагато полегшують користування програмою.

Основне вікно програми складається з робочої області і меню, а також меню з'являється при натисканні правої кнопки миші (мал. 3.1).

Все управління програмою зазвичай здійснюється графічним маніпулятором (мишею) і набором гарячих клавіш на клавіатури, можна керувати тільки клавіатурою.

Система спадаючих меню дозволяє оперативно керувати процесом проектування. Меню "Файл" складається з пунктів відкриття проекту, збереження проекту, відкриття нового проекту, виходу з програми. Меню "Правка" дозволяє посредствам буфера обміну інформацією обмінюватися інформацією між проектами, а також змінювати поточний проект, копіювати об'єкти в буфер обміну і з нього, видаляти частину об'єктів (рис 3.2).

Меню "Створити" крім безпосередньо прямого вибору в лінійці меню, через меню "Правка", можна отримати натиснувши праву кнопку миші, з нього можна вибрати об'єкт (документ або функцію OLE, або зареєструвати додаток OLE Automation) який необхідно створити. Після вибору об'єкта запускається редактор властивостей вибраного об'єкта (рис.3.3). Як видно з ілюстрації, у цих формах все властивості описані безпосередньо у формі.

Всі властивості документів і функцій після заповнення зберігаються в змінних головного модуля. Призначення змінних головного модуля, а значить і призначення властивостей об'єктів були описані в попередньому розділі

Заповнивши ці форми створюється заданий об'єкт який можна переміщати покажчиком миші. Правою кнопкою миші можна через що виникло меню завжди змінити властивості об'єкта (вибравши "Властивості").

Крім того використовується наступні способи управління об'єктами створеними в процесі проектування. Можливе об'єднання об'єктів в групу, для цього потрібно натиснувши ліву кнопку миші не відпускаючи обвести ті об'єкти які об'єднуються в групу, при відпуску кнопки об'єкти виділяться в рамку. З цими виділеними об'єктами можливо тепер виконувати групові операції (переміщення, видалення копіювання і т.д.) через меню "Правка" або по правій кнопці миші.

Над документами також виконуються власне операції їх зміни, тобто у випадку застосування програми в конструкторському проектуванні, їх зміна можлива або безпосередньо додатком яке обробляє цей документ, або через вже створені OLE функції які у неявному вигляді викликають програми та обробляють документи. Так запустити функцію OLE можна подвійним клацанням лівої кнопки миші на потрібній функції. А для запуску програми обробного певний документ потрібно двічі клацнути мишкою на документі.

Після роботи з конкретним документом виробляється подія "Документ був змінений" яке повинні обробляти всі вихідні з документа функції OLE (якщо звичайно у них був встановлений прапор властивості "Автоматичне виконання функції при зміні вхідного документа"). Що тягне за собою виконання цих функцій, тобто зміна документів вихідних з функції, що в свою чергу може спричинити за собою виконання інших функцій. Процес може стати циклічним (якщо вхідні документи будуть змінені вихідними функціями). Щоб цього не сталося необхідно користуватися прапором "Запит користувача перед виконанням" у властивостях функції OLE. Установка цього прапора спричинить собою запит користувачеві про необхідність виконання цієї функції перед її виконанням. Тим самим надається можливість користувачеві зациклити процес зворотним зв'язком, що іноді необхідно (наприклад, для підбору потрібного теплового режиму), а потім перервати його.

Перед виходом з програми контролера, програмою буде поставлено питання про необхідність збереження зміненого проекту. Якщо проект потрібен буде в подальшому, його потрібно зберегти.

Якщо необхідність в програмі контролера відпала, то її можна видалити з диска. Однак програма контролера не забезпечена спеціальним файлом унінсталляціі, як це вимагає стандарт програм для Windows 95, оскільки для створення цього файлу програмісту необхідно досконально знати всю систему Windows, що зараз при нестачі інформації про Windows (тому що ця система є відносно новою) у наших умовах неможливо. По цьому для видалення програми з носія крім видалення самої директорії програми контролера необхідно видалити всі DLL-файли з директорія Windows самостійно. Список всіх файлів програми наведено у додатку.

КОНСТРУКТОРСЬКІ РОЗРАХУНКИ

Показники надійності

Основними конструкторськими розрахунками для ЕВА, є розрахунок надійності пристрою і розрахунок міцності друкованої плати. Розглянемо теоретичну підставу цих конструкторських розрахунків.

Всі промислові вироби характеризуються якістю, тобто сукупністю властивостей, які відрізняють даний продукт від інших і визначають ступінь його придатності для експлуатації за своїм призначенням. Для ЕВА це перш за все сукупність конструкторських, технологічних та експлуатаційних характеристик. У процесі експлуатації відбуваються зміни цих характеристик у слідстві зносу і необоротних процесів старіння. Таким чином змінюється якість виробу в часі, а характеристикою зміни якості в часі є показник званий надійністю.

Під надійністю розуміють властивість виробу виконувати задані функції, зберігати свої експлуатаційні показники в заданих межах протягом необхідного проміжку часу або необхідної напрацювання при дотриманні режимів експлуатації, правил обслуговування, зберігання і т.д.

Надійність не може бути виміряна безпосередньо як будь-яка фізична величина. Вона може бути тільки кількісно оцінена або передбачена. Для оцінки основних показників надійності використовують математичний апарат теорії ймовірності

Показники надійності неремонтіруемих систем. Неремонтіруемие системи працюють до першої відмови після чого замінюються новими. Усі кількісні показники надійності неремонтіруемих систем є загальними і виражаються одними і тими ж математичними залежностями, але їх конкретні числові значення залежать від режимів роботи систем, що вивчаються.

Показники надійності неремонтіруемих систем базуються на поняттях функцій надійності Р (t) і функції відмови Q (t), пов'язаних залежністю P (t) = 1 - Q (t). Обидві вони залежать від часу t.

Ймовірністю безвідмовної роботи P (t) називають ймовірність того, що в заданому інтервалі часу або заданої напрацювання ti відмов у системі не виникає, тобто P (ti) = P (T> ti), де Т - випадкова величина характеризує час напрацювання системи до виникнення в ній відмови. Відповідно ймовірністю виникнення відмови в системі Q (ti) називається ймовірність того, що в період напрацювання ti в ній обов'язково відбудеться відмова, тобто Q (ti) = P (T <ti).

Теоретичне значення ймовірності безвідмовної роботи ЕВА зручно визначити наступним чином:

(4.1),

де

N1i - число виробів, які відмовили під час випробувань на i-тому інтервалі часу;

m = t / t - число інтервалів

t - час випробування

t - тривалість інтервалу часу

За аналогією з (4.1) статистична ймовірність безвідмовної роботи ЕВА

(4.2),

Природно, чим більше N, тим більш точно дотримується рівності, і тим точніше стають значення величин P (ti) і P '(ti).

Імовірність безвідмовної роботи може бути визначена і для довільного інтервалу часу (t1; t2), тобто не з моменту включення системи. У цьому випадку говорять про умовної ймовірності безвідмовної роботи системи P (t1; t2) до періоду (t1; t2), маючи на увазі, що в момент часу t1 система перебуває в працездатному стані. Умовна ймовірність P (t1; t2) визначається співвідношенням

P (t1; t2) = P (t2) / P (t1) (4.3)

де

P (t1) і P (t2) - відповідно значення функцій надійності на початку і наприкінці напрацювання.

Щільністю розподілу наробітку до відмови f (t) називають похідну за часом від функції відмови Q (t):

(4.4)

З (4.4) випливає, що величина f (t) dt характеризує безумовну ймовірність того, що система обов'язково відмовить в інтервалі часу (t; t + dt) за умови, що в момент часу t вона перебувала в працездатному стані.

Найбільш поширеним показником надійності є інтенсивність відмов. Інтенсивність відмов (T) являє собою умовну ймовірність виникнення відмови в системі в певний момент часу напрацювання за умови, що до цього моменту відмов у системі не було. Величина інтенсивності визначається відношенням: (T) = f (t) / P (t). Приблизно її можна оцінити таким відношенням:

,

де

N1 - число виробів, які відмовили при випробуваннях у плині часу t

N - кількість виробів, працездатних до початку випробувань.

Умовна працездатність системи в момент початку напрацювання можна записати у вигляді P (0) = 1. Тоді з (4.3) і (4.4) випливає що

Аналогічно може бути визначена умовна ймовірність

Таким чином ми розглянули три показники надійності. Очевидно, що достатньо знати одну (будь-яку) з них, щоб визначити два інших. Таким чином всі три показники є рівноправними. Однак у більшості випадків перевагу віддають інтенсивності відмов.

Як показник надійності використовують середній наробіток до відмови tcp. Середнє напрацювання до відмови представляє собою математичне сподівання M (t) випадкової величини t

Вид функцій f (t) і P (t) визначається конкретними законами розподілу випадкової величини t. Середнє напрацювання до відмови - це очікуваний час справної роботи системи до першої відмови. Приблизно її можна оцінити так:

,

де

tcp i = (ti - ti-1) / 2

(Ti; ti-1) - час на початку і наприкінці i-того інтервалу.

Таким чином ми розглянули основні показники надійності систем. / 4 /

4.2. Методика розрахунку надійності

На практиці найчастіше використовується ескізний (орієнтовний) повний розрахунок надійності електронної апаратури. Розрахунок надійності нерезервовані системи полягає в знаходженні загальної інтенсивності відмов, напрацювання на відмову Тср та ймовірності безвідмовної роботи P (t). Ескізний розрахунок надійності нерезервованої системи можна проводити в наступному порядку:

всі елементи системи розбиваються на групи з однаковими або близькими інтенсивностями відмов і підраховується кількість елементів N в кожній i-тій групі;

за таблицями наведеним у / 4 / визначають значення інтенсивності відмов для елементів i-тої групи;

розраховують інтенсивність відмов системи як суму добутків Ni, c урахуванням поправочного коефіцієнта

,

де

m - загальна кількість груп

k - поправочний коефіцієнт, що враховує зміну середньої інтенсивності відмов елементів апаратури в залежності від її призначення (величина зазвичай таблична);

визначають напрацювання на відмову

;

розраховують залежність ймовірності безвідмовної роботи системи від часу за формулою

;

Таким чином проводиться розрахунок надійності.

4.3. Методика визначення механічної міцності ПП

На ПП, як правило, встановлюється декілька десятків інтегральних схем (ІС) і електроелементів (ЕРЕ)

Нехай на плату впливає навантаження Q, прискорення а, необхідно перевірити, чи не призведуть ці дії до виникнення неприпустимих напружень на платі

Величина гранично допустимої напруги G задана. При впливі на плату навантаження з прискоренням, на неї буде діяти деформація згину та кручення. Для розрахунку напруг, які виникають плату прийнято представляти у вигляді балкової системи, що лежить на опорах.

Для знаходження діючих на плату сил можна запропонувати наступний алгоритм.

Визначаємо координати Хi, Yi, i-х елементів на платі - відстань від осей до центру ваги елементів (мм)

Визначаємо рівнодіючу прикладених до плати сил

де

Рi - сила тяжіння i-того елемента, Н;

к - кількість елементів, шт.

Знаходимо загальний центр ваги прикладених сил

і (4.5)

де

Xi і Yi - координати центру ваги плати, мм.

Визначимо силу. Чинну на плату:

, (4.6)

де

а - прискорення, що впливає на плату

Розраховуємо реакції в опорах:

(4.7) (4.8)

де

l - відстань між опорами

Обчислюємо максимальний згинальний момент:

Mmax = RAXC (4.9)

Визначаємо крутний момент крутний момент:

Mk = Q d, (4.10)

де

d - величина зміщення центру ваги від осі симетрії плати

(4.11)

де

b - ширина плати

Знаходимо напругу, що викликається в платі крутним моментом:

(4.12),

де

h - товщина плати

- Коефіцієнт міцності, рівний 0.333.

Перевіряємо виконання рівності

(4.13)

де

- Максимально допустима напруга в платі

Якщо нерівність (4.13) виконується, то слід зробити висновок, що докладені навантаження не приведуть до пошкодження плати. У випадку, якщо нерівність (4.13) не виконується, потрібно передбачити заходи, необхідні для додаткового кріплення плати.

4.3. Методика розрахунку власних коливань блоку

Розрахунок частоти власних коливань блоку можна привести, замінивши конструкцію його еквівалентним розрахунковим схемою у вигляді блочної схеми / 5 /.

Частоту власних коливань прямокутної пластини для всіх випадків закріплення її країв можна визначити наступним чином:

, (4.14)

де

а - довжина пластини, м;

D - циліндрична жорсткість пластини

, (4.15)

Е - модуль пружності;

- Коефіцієнт Пуассона;

q - прискорення вільного падіння;

- Щільність матеріалу

- Коефіцієнт, значення якого залежить від способу закріплення сторін пластини

Для зручності користування вираз (4.14) приведемо до вигляду:

, (4.16)

де

В - частотна постійна, що залежить від способу закріплення пластини

Якщо пластина не сталева, а виконана з будь-якого іншого матеріалу, то в (4.16) вводиться поправочний коефіцієнт kM на матеріал

де

Е і - Модуль пружності і щільність застосовуваного матеріалу;

ЄС і С - модуль пружності і щільність сталі.

Для обліку навантаження при розподіленому навантаженні вводять поправочний коефіцієнт маси елементів

,

де

QЕ і QЕ - маса пластини і маса елементів, рівномірно розподілених по пластині;

Таким чином вираз (4.14) для визначення частоти власних коливань набуває вигляду

(4.17)

Важливо, щоб резонансна частота ПП відрізнялася від частоти вимушених коливань на вході, по крайней мере в два рази. При цьому виключається входження в резонанс, небезпечний в вібросістеме.

Друкована плата повинна мати значну втомної довговічністю при дії вібрацій, для цього необхідно, щоб мінімальна частота власних коливань плати задовольняла умові:

, (4.18)

де

jmax - вібраційні перевантаження

b - розмір короткої сторони плати

- Безрозмірна постійна, числове значення якої залежить від значень частоти власних коливань і які впливають прискорень.

4.5. Розрахункова частина

У розрахунковій частині проекту в якості прикладу конструкторського розрахунку будь-якої конструкторської одиниці представимо конструкторський розрахунок плати підсилювача імпульсів (УІ).

Текст програми

'*****************************

'Main Module Code

'*****************************

Option Explicit

Option Base 0

Public MenuFrom As Integer

Public Canceled As Boolean

Public SelectOn As Boolean

Public SelectIs As Boolean

Public ImageCo As Integer

Public MouseX As Integer

Public MouseY As Integer

Public TotalDocCo As Integer

Public TotalFunCo As Integer

Public TotalRegCo As Integer

Public CurDocument As Integer

Public CurFunction As Integer

Public DocumentIsChanged As Boolean

Public Type RegistrationType

TotalNumber As Long

Discription As String

FileName As String NameApp As String

FileMask As String

End Type

Public Registrations () As RegistrationType

Public RegistrationCo As Integer

Public Type DocumentType

TotalNumber As Long

FileName As String

CreateDateTime As String

UsedProgramm As Long

Discription As String

ImageIcon As String

ImageText As String

X As Integer

Y As Integer

OutputFunPoints () As Integer

OutputFunPointCo As Integer

OutputDocPoints () As Integer

OutputDocPointCo As Integer

End Type

Public Documents () As DocumentType

Public DocumentCo As Integer

Public Type FunctionType

TotalNumber As Long

FileName As String

CreateDateTime As String

Path As String

UsedProgramm As String

AutomatFunction As String

AutoExeFlag As Boolean

AskBeforeExe As Boolean

Discription As String

ImageIcon As String

ImageText As String

X As Integer

Y As Integer

DocumentsAndFunctionsLink As String

InputDocPoints () As Integer

InputDocPointCo As Integer

OutputDocPoints () As Integer

OutputDocPointCo As Integer

InputFunPoints () As Integer

InputFunPointCo As Integer

OutputFunPoints () As Integer

OutputFunPointCo As Integer

End Type

Public Functions () As FunctionType

Public FunctionCo As Integer

Public Sub ShowDocumentProperty (DocNumber As Integer)

On Error GoTo Err1

MakeDocForm.Label4 (0). Caption = FileLen (Documents (DocNumber). FileName)

MakeDocForm.Label4 (1). Caption = FileDateTime (Documents (DocNumber). FileName)

MakeDocForm.Label4 (2). Caption = Documents (DocNumber). CreateDateTime

MakeDocForm.IconText.Text = Documents (DocNumber). ImageText

MakeDocForm.Icon9412_.Picture = LoadPicture (Documents (DocNumber). ImageIcon)

MakeDocForm.ImageIconText.Caption = Documents (DocNumber). ImageIcon

MakeDocForm.Discrip.Text = Documents (DocNumber). Discription

MakeDocForm.DocumentName = Documents (DocNumber). FileName

If Documents (DocNumber). UsedProgramm = -1 Then

MakeDocForm.Combo1.ListIndex = RegistrationCo + 1

Else

MakeDocForm.Combo1.ListIndex = GetREGIndex (Documents (DocNumber). UsedProgramm)

End If

Exit Sub

Err1:

Case vbAbort

End

Case vbRetry

Resume 0

Case vbIgnore

End Select

End Sub

Public Sub SaveRegCards ()

Dim FileNumber As Integer

Dim a As Integer

On Error GoTo Err1

FileNumber = FreeFile

Open App.Path & "RegisterCards" For Output As FileNumber

Write # FileNumber, TotalRegCo, RegistrationCo

For a = 0 To RegistrationCo

With Registrations (a)

Write # FileNumber,. TotalNumber,. Discription,. FileName,. NameApp,. FileMask

End With

Next a

Close FileNumber

Exit Sub

Err1:

& Chr (13) & Chr (10) & Err.Number & Chr (13) & Chr (10) & _

Err.Description, vbAbortRetryIgnore + vbCritical)

Case vbAbort

End

Case vbRetry

Resume 0

End Select

End Sub

Public Sub MemberDocumentProperty (DocNumber As Integer)

Documents (DocNumber). ImageText = MakeDocForm.IconText.Text

Documents (DocNumber). ImageIcon = MakeDocForm.ImageIconText.Caption

Documents (DocNumber). Discription = MakeDocForm.Discrip.Text

Documents (DocNumber). FileName = MakeDocForm.DocumentName.Text

Documents (DocNumber). CreateDateTime = MakeDocForm.Label4 (0). Caption

If MakeDocForm.Combo1.ListIndex = RegistrationCo + 1 Then

Documents (DocNumber). UsedProgramm = -1

Else

Documents (DocNumber). UsedProgramm = Registrations (MakeDocForm.Combo1.ListIndex). TotalNumber

End If

End Sub

Public Sub SaveProject (ProjectName As String)

Dim FileNumber As Integer

Dim a As Integer

Dim b As Integer

On Error GoTo Err1

FileNumber = FreeFile

Open ProjectName For Output As FileNumber

Write # FileNumber, TotalDocCo, TotalFunCo, DocumentCo, FunctionCo

For a = 0 To DocumentCo

With Documents (a)

Write # FileNumber,. TotalNumber,. FileName,. CreateDateTime,. UsedProgramm, _

. Discription,. ImageIcon,. ImageText,. X,. Y,. OutputFunPointCo, _

. OutputDocPointCo

For b = 0 To. OutputFunPointCo

Write # FileNumber,. OutputFunPoints (b)

Next b

For b = 0 To. OutputDocPointCo

Write # FileNumber,. OutputDocPoints (b)

Next b

End With

Next a

For a = 0 To FunctionCo

With Functions (a)

Write # FileNumber,. TotalNumber,. FileName,. CreateDateTime,. UsedProgramm, _

. AutomatFunction,. AutoExeFlag,. AskBeforeExe,. Discription, _

. ImageIcon,. ImageText,. X,. Y,. DocumentsAndFunctionsLink, _

. OutputFunPointCo,. OutputDocPointCo,. InputFunPointCo, _

. InputDocPointCo

For b = 0 To. OutputFunPointCo

Write # FileNumber,. OutputFunPoints (b)

Next b

For b = 0 To. OutputDocPointCo

Write # FileNumber,. OutputDocPoints (b)

Next b

For b = 0 To. InputFunPointCo

Write # FileNumber,. InputFunPoints (b)

Next b

For b = 0 To. InputDocPointCo

Write # FileNumber,. InputDocPoints (b)

Next b

End With

Next a

Close FileNumber

Exit Sub

Err1:

& Chr (13) & Chr (10) & Err.Number & Chr (13) & Chr (10) & _

Err.Description, vbAbortRetryIgnore + vbCritical)

Case vbAbort

End

Case vbRetry

Resume 0

End Select

End Sub

Public Sub LoadRegCards ()

On Error GoTo Err1

Dim FileNumber As Integer

Dim a As Integer

FileNumber = FreeFile

Open App.Path & "RegisterCards" For Input As FileNumber

Input # FileNumber, TotalRegCo, RegistrationCo

If RegistrationCo = -1 Then

Close FileNumber

Exit Sub

End If

ReDim Registrations (RegistrationCo)

For a = 0 To RegistrationCo

With Registrations (a)

Input # FileNumber,. TotalNumber,. Discription,. FileName,. NameApp,. FileMask

End With

Next a

Close FileNumber

Exit Sub

Err1:

& Chr (13) & Chr (10) & Err.Number & Chr (13) & Chr (10) & _

Err.Description, vbAbortRetryIgnore + vbCritical)

Case vbAbort

End

Case vbRetry

Resume 0

Case vbIgnore

RegistrationCo = -1

End Select

End Sub

Public Sub LoadProject (ProjectName As String)

On Error GoTo Err1

Dim FileNumber As Integer

Dim a As Integer

Dim b As Integer

FileNumber = FreeFile

Open ProjectName For Input As FileNumber

Input # FileNumber, TotalDocCo, TotalFunCo, DocumentCo, FunctionCo

If DocumentCo -1 Then

ReDim Documents (DocumentCo)

For a = 0 To DocumentCo

With Documents (a)

Input # FileNumber,. TotalNumber,. FileName,. CreateDateTime,. UsedProgramm, _

. Discription,. ImageIcon,. ImageText,. X,. Y,. OutputFunPointCo, _

. OutputDocPointCo

If. OutputFunPointCo -1 Then

ReDim. OutputFunPoints (. OutputFunPointCo)

For b = 0 To. OutputFunPointCo

Input # FileNumber,. OutputFunPoints (b)

Next b

End If

If. OutputFunPointCo -1 Then

ReDim. OutputDocPoints (. OutputDocPointCo)

For b = 0 To. OutputDocPointCo

Input # FileNumber,. OutputDocPoints (b)

Next b

End If

End With

Next a

End If

If FunctionCo -1 Then

ReDim Functions (FunctionCo)

For a = 0 To FunctionCo

With Functions (a)

Input # FileNumber,. TotalNumber,. FileName,. CreateDateTime,. UsedProgramm, _

. AutomatFunction,. AutoExeFlag,. AskBeforeExe,. Discription, _

. ImageIcon,. ImageText,. X,. Y,. DocumentsAndFunctionsLink, _

. OutputFunPointCo,. OutputDocPointCo,. InputFunPointCo, _

. InputDocPointCo

If. OutputFunPointCo -1 Then

ReDim. OutputFunPoints (. OutputFunPointCo)

For b = 0 To. OutputFunPointCo

Input # FileNumber,. OutputFunPoints (b)

Next b

End If

If. OutputDocPointCo -1 Then

ReDim. OutputDocPoints (. OutputDocPointCo)

For b = 0 To. OutputDocPointCo

Input # FileNumber,. OutputDocPoints (b)

Next b

End If

If. InputFunPointCo -1 Then

ReDim. InputFunPoints (. InputFunPointCo)

For b = 0 To. InputFunPointCo

Input # FileNumber,. InputFunPoints (b)

Next b

End If

If. InputDocPointCo -1 Then

ReDim. InputDocPoints (. InputDocPointCo)

For b = 0 To. InputDocPointCo

Input # FileNumber,. InputDocPoints (b)

Next b

End If

End With

Next a

End If

Close FileNumber

Exit Sub

Err1:

& Chr (13) & Chr (10) & Err.Number & Chr (13) & Chr (10) _

& Err.Description, vbAbortRetryIgnore + vbCritical)

Case vbAbort

End

Case vbRetry

Resume 0

Case vbIgnore

FunctionCo = -1

DocumentCo = -1

End Select

End Sub

Public Function GetREGIndex (TotalNumber As Long) As Integer

Dim a As Integer

For a = 0 To RegistrationCo

If Registrations (a). TotalNumber = TotalNumber Then

GetREGIndex = a

Exit For

End If

Next a

End Function

Public Function GetDOCIndex (TotalNumber As Long) As Integer

Dim a As Integer

For a = 0 To DocumentCo

If Documents (a). TotalNumber = TotalNumber Then

GetDOCIndex = a

Exit For

End If

Next a

End Function

Public Function GetFUNIndex (TotalNumber As Long) As Integer

Dim a As Integer

For a = 0 To FunctionCo

If Functions (a). TotalNumber = TotalNumber Then

GetFUNIndex = a

Exit For

End If

Next a

End Function

Public Sub ShowProject ()

Dim a As Integer

With MainForm

For a = 0 To DocumentCo

ImageCo = ImageCo + 1

Load. ImageIcon (ImageCo)

. ImageIcon (ImageCo). Top = Documents (a). Y

. ImageIcon (ImageCo). Left = Documents (a). X

. ImageIcon (ImageCo). Visible = True

. ImageIcon (ImageCo). Enabled = True

. ImageIcon (ImageCo). Picture = LoadPicture (Documents (a). ImageIcon)

. ImageIcon (ImageCo). Tag = Documents (a). TotalNumber

Load. ImageText (ImageCo)

. ImageText (ImageCo). Top = Documents (a). Y + 500

. ImageText (ImageCo). Left = Documents (a). X

. ImageText (ImageCo). Visible = True

. ImageText (ImageCo). Enabled = True

. ImageText (ImageCo). Caption = Documents (a). ImageText

. ImageText (ImageCo). Tag = 1

Next a

End With

End Sub

'******************************

'Main Form Code

'******************************

Option Explicit

Option Base 0

Private Sub Form_DragDrop (Source As Control, X As Single, Y As Single)

Dim a As Integer

Dim dX As Integer

Dim dY As Integer

If SelectIs = True Then

dX = X - Source.Left

dY = Y - Source.Top

For a = 0 To ImageCo

If ImageIcon (a). BorderStyle = 1 Then

If ImageText (a). Tag = 1 Then

Documents (GetDOCIndex (ImageIcon (a). Tag)). X = ImageIcon (a). Left + dX

Documents (GetDOCIndex (ImageIcon (a). Tag)). Y = ImageIcon (a). Top + dY

End If

ImageIcon (a). Left = ImageIcon (a). Left + dX

ImageIcon (a). Top = ImageIcon (a). Top + dY

ImageText (a). Left = ImageIcon (a). Left

ImageText (a). Top = ImageIcon (a). Top + 500

End If

Next a

Else

If ImageText (Source.Index). Tag = 1 Then

Documents (GetDOCIndex (Source.Tag)). X = X

Documents (GetDOCIndex (Source.Tag)). Y = Y

End If

Source.Left = X

Source.Top = Y

ImageText (Source.Index). Left = X

ImageText (Source.Index). Top = Y + 500

End If

End Sub

Private Sub Form_Load ()

Dim a As Integer

LoadRegCards

MakeDocForm.Combo1.Clear

For a = 0 To RegistrationCo

MakeDocForm.Combo1.AddItem Registrations (a). NameApp, a

Next a

MakeDocForm.Combo1.AddItem "Використовувати стандартний обробник", RegistrationCo + 1

MakeDocForm.Combo1.ListIndex = RegistrationCo + 1

LoadRegCards

ImageCo = -1

LoadProject App.Path & "pro1.prj"

ShowProject

SaveProject App.Path & "pro1.prj"

End Sub

Private Sub Form_MouseDown (Button As Integer, Shift As Integer, X As Single, Y As Single)

If Button = 1 Then

MouseX = X

MouseY = Y

SelectOn = True

With selectrec

. Visible = True

. Height = 0

. Width = 0

. Left = X

. Top = Y

End With

End If

End Sub

Private Sub Form_MouseMove (Button As Integer, Shift As Integer, X As Single, Y As Single)

If SelectOn = True Then

With selectrec

If Y <MouseY Then

. Top = Y

. Height = MouseY - Y

Else

. Top = MouseY

. Height = Y - MouseY

End If

If X <MouseX Then

. Left = X

. Width = MouseX - X

Else

. Left = MouseX

. Width = X - MouseX

End If

End With

End If

End Sub

Private Sub Form_MouseUp (Button As Integer, Shift As Integer, X As Single, Y As Single)

Dim a As Integer

If SelectOn = False Then

MouseX = X

MouseY = Y

If Button = 2 Then

MenuMake.Visible = True

MenuRegistration.Visible = True

MenuPropertyes.Visible = False

MenuSeparator.Visible = False

If SelectIs = True Then

MenuDelete.Visible = True

MenuCut.Visible = True

MenuCopy.Visible = True

Else

MenuDelete.Visible = False

MenuCut.Visible = False

MenuCopy.Visible = False

End If

'MenuPaste.Visible = False

MenuFrom = -1

MainForm.PopupMenu RightButtonMenuOnForm

End If

Else

SelectOn = False

selectrec.Visible = False

SelectIs = False

For a = 0 To ImageCo

If (ImageIcon (a). Top> selectrec.Top) And _

(ImageIcon (a). Left> selectrec.Left) And _

(ImageIcon (a). Top <(selectrec.Top + selectrec.Height)) And _

(ImageIcon (a). Left <(selectrec.Left + selectrec.Width)) Then

SelectIs = True

ImageIcon (a). BorderStyle = 1

Else

ImageIcon (a). BorderStyle = 0

End If

Next a

End If

End Sub

Private Sub Form_Unload (Cancel As Integer)

SaveProject App.Path & "pro1.prj"

End

End Sub

Private Sub ImageIcon_MouseMove (Index As Integer, Button As Integer, Shift As Integer, X As Single, Y As Single)

If Button = 1 Then

ImageIcon (Index). Drag

End If

End Sub

Private Sub ImageIcon_MouseUp (Index As Integer, Button As Integer, Shift As Integer, X As Single, Y As Single)

If Button = 2 Then

MenuMake.Visible = False

MenuRegistration.Visible = False

MenuPaste.Visible = False

MenuPropertyes.Visible = True

MenuSeparator.Visible = True

MenuFrom = Index

PopupMenu RightButtonMenuOnForm

End If

End Sub

Private Sub Menu_Edit_Click ()

MainForm.PopupMenu RightButtonMenuOnForm

End Sub

Private Sub MenuDelete_Click ()

Dim a As Integer

If SelectIs = True Then

For a = 0 To ImageCo

If ImageIcon (a). BorderStyle = 1 Then

Delete a

End If

Next a

SelectIs = False

Else

Delete MenuFrom

End If

End Sub

Private Sub MenuMakeDocument_Click ()

DocumentCo = DocumentCo + 1

TotalDocCo = TotalDocCo + 1

ReDim Preserve Documents (DocumentCo)

Documents (DocumentCo). X = MouseX

Documents (DocumentCo). Y = MouseY

CurDocument = DocumentCo

DocumentIsChanged = True

MakeDocForm.Label4 (0). Caption = "0"

MakeDocForm.Label4 (1). Caption = str (Now)

MakeDocForm.Label4 (2). Caption = str (Now)

MakeDocForm.IconText.Text = "Документ"

MakeDocForm.Icon9412_.Picture = LoadPicture (App.Path & "DefDoc.ico")

MakeDocForm.ImageIconText = App.Path & "DefDoc.ico"

MakeDocForm.Discrip.Text = ""

MakeDocForm.DocumentName = ""

Canceled = False

MakeDocForm.Show vbModal

If Canceled = True Then

DocumentCo = DocumentCo - 1

TotalDocCo = TotalDocCo - 1

ReDim Preserve Documents (DocumentCo)

Exit Sub

End If

MemberDocumentProperty DocumentCo

Documents (DocumentCo). TotalNumber = TotalDocCo

Documents (DocumentCo). OutputFunPointCo = -1

Documents (DocumentCo). OutputDocPointCo = -1

ImageCo = ImageCo + 1

Load ImageIcon (ImageCo)

ImageIcon (ImageCo). Top = Documents (DocumentCo). Y

ImageIcon (ImageCo). Left = Documents (DocumentCo). X

ImageIcon (ImageCo). Visible = True

ImageIcon (ImageCo). Enabled = True

ImageIcon (ImageCo). Picture = LoadPicture (Documents (DocumentCo). ImageIcon)

ImageIcon (ImageCo). Tag = Documents (DocumentCo). TotalNumber

Load ImageText (ImageCo)

ImageText (ImageCo). Top = Documents (DocumentCo). Y + 300

ImageText (ImageCo). Left = Documents (DocumentCo). X

ImageText (ImageCo). Visible = True

ImageText (ImageCo). Enabled = True

ImageText (ImageCo). Caption = Documents (DocumentCo). ImageText

ImageText (ImageCo). Tag = 1'**************** 1 = Це документ

End Sub

Private Sub MenuPropertyes_Click ()

Dim temp As Integer

If MenuFrom> = 0 Then

If ImageText (MenuFrom). Tag = 1 Then

temp = GetDOCIndex (ImageIcon (MenuFrom). Tag)

ShowDocumentProperty temp

MakeDocForm.Show vbModal

MemberDocumentProperty temp

ImageText (MenuFrom). Caption = Documents (temp). ImageText

ImageIcon (MenuFrom). Picture = LoadPicture (Documents (temp). ImageIcon)

End If

Else

End If

End Sub

Private Sub MenuRegistration_Click ()

RegistrForm.Show vbModal

End Sub

Public Sub Delete (Index As Integer)

Dim a As Integer

Dim b As Integer

If ImageText (Index). Tag = 1 Then

b = GetDOCIndex (ImageIcon (Index). Tag)

For a = b To DocumentCo - 1

LSet Documents (a) = Documents (a + 1)

Next a

DocumentCo = DocumentCo - 1

End If

For a = 0 To ImageCo

Unload ImageText (a)

Unload ImageIcon (a)

Next a

ImageCo = -1

SaveProject App.Path & "temp ~. Prj"

LoadProject App.Path & "temp ~. Prj"

ShowProject

End Sub

'********************

'Make doc form code

'********************

Option Explicit

Private Sub Cancel_Click ()

Canceled = True

Hide

End Sub

Private Sub Command1_Click ()

On Error GoTo Err1

RegDialog2.Flags = cdlOFNHideReadOnly

If Combo1.ListIndex (RegistrationCo + 1) Then

RegDialog2.Filter = "Âñå ôàéëû |*.*|" & _

Registrations (Combo1.ListIndex). NameApp & "|" & _

Registrations (Combo1.ListIndex). FileMask

Else

RegDialog2.Filter = "Âñå ôàéëû |*.*"

End If

RegDialog2.ShowOpen

DocumentName.Text = RegDialog2.FileName

Err1:

End Sub

Private Sub Command2_Click ()

On Error GoTo Err1

RegDialog.Flags = cdlOFNFileMustExist + cdlOFNHideReadOnly

RegDialog.ShowOpen

Icon9412_.Picture = LoadPicture (RegDialog.FileName)

ImageIconText = RegDialog.FileName

Err1:

End Sub

Private Sub DocumentName_Change ()

DocumentIsChanged = True

End Sub

Private Sub Form_Activate ()

DocumentIsChanged = False

End Sub

Private Sub OkButton_Click ()

Dim ErrorFlag As Boolean

Dim tmp As Integer

Dim CurObject As Object

Dim retShell As Long

On Error GoTo Err1

If DocumentName.Text = "" Then

DocumentName.SetFocus

Exit Sub

End If

If DocumentIsChanged Then

ErrorFlag = False

tmp = FileLen (DocumentName.Text)

If ErrorFlag = True Then

tmp = FreeFile

Open DocumentName.Text For Output As tmp

Close tmp

End If

End If

Hide

Exit Sub

Err1:

If Err.Number = 53 Then

ErrorFlag = True

Else

Select Case MsgBox ("Ïðîèçîøëà îøèáêà íîìåð:" & Err.Number & _

Chr (13) & Chr (10) _

& Err.Description, vbAbortRetryIgnore + vbCritical)

Case vbAbort

End

Case vbRetry

Resume 0

End Select

End If

Resume Next

End Sub

'***********************

'Registration form code

'***********************

Option Explicit

Dim CurIndex As Integer

Private Sub Browser_Click ()

On Error GoTo Err1

RegDialog.Flags = cdlOFNFileMustExist + cdlOFNHideReadOnly

RegDialog.ShowOpen

Path = RegDialog.FileName

Err1:

End Sub

Private Sub Cancel_Click ()

LoadRegCards

Hide

End Sub

Private Sub Combo1_Click ()

ShowRegCard Combo1.ListIndex

End Sub

Private Sub DestroyReg_Click ()

Dim a As Integer

For a = CurIndex To RegistrationCo - 1

LSet Registrations (a) = Registrations (a + 1)

Next a

RegistrationCo = RegistrationCo - 1

If RegistrationCo> -1 Then

ReDim Preserve Registrations (RegistrationCo)

If CurIndex> RegistrationCo Then CurIndex = CurIndex - 1

ComboRemake

CardShow CurIndex

Combo1.ListIndex = CurIndex

'ShowRegCard CurIndex

Else

EnabledAll RegistrationCo

End If

EnabledAll RegistrationCo

End Sub

Private Sub Form_Activate ()

EnabledAll RegistrationCo

If RegistrationCo = -1 Then Exit Sub

ComboRemake

CurIndex = 0

CardShow CurIndex

Combo1.ListIndex = CurIndex

End Sub

Private Sub NewReg_Click ()

TotalRegCo = TotalRegCo + 1

RegistrationCo = RegistrationCo + 1

ReDim Preserve Registrations (RegistrationCo)

Registrations (RegistrationCo). NameApp = InputBox ("Ââåäèòå èìÿ ïðèëîæåíèÿ",, "Ïðèëîæåíèå" + str (RegistrationCo + 1))

If Registrations (RegistrationCo). NameApp = "" Then

ReDim Preserve Registrations (RegistrationCo)

TotalRegCo = TotalRegCo - 1

RegistrationCo = RegistrationCo - 1

Exit Sub

End If

Registrations (RegistrationCo). TotalNumber = TotalRegCo

EnabledAll RegistrationCo

ComboRemake

Combo1.ListIndex = RegistrationCo

'ShowRegCard RegistrationCo

'Debug.Print

End Sub

Private Sub OkButton_Click ()

MemberCard

SaveRegCards

Hide

End Sub

Private Sub Rename_Click ()

Dim a As Integer

Dim str As String

a = Combo1.ListIndex

str = InputBox ("Ââåäèòå èìÿ ïðèëîæåíèÿ",, Registrations (a). NameApp)

If str "" Then Registrations (a). NameApp = str

ComboRemake

Combo1.ListIndex = a

'ShowRegCard a

End Sub

Private Sub ShowRegCard (NumRegCard As Integer)

MemberCard

CardShow NumRegCard

End Sub

Public Sub ComboRemake ()

Dim a As Integer

Combo1.Clear

For a = 0 To RegistrationCo

Combo1.AddItem Registrations (a). NameApp, a

Next a

End Sub

Public Sub EnabledAll (Yes As Integer)

If Yes = -1 Then

ComboRemake

Browser.Enabled = False

DestroyReg.Enabled = False

Combo1.Enabled = False

Rename.Enabled = False

Path.Enabled = False

Discrip.Enabled = False

ListExt.Enabled = False

Path.Text = ""

Discrip.Text = ""

ListExt.Text = ""

Label1.Enabled = False

Label2.Enabled = False

Label3.Enabled = False

Label4.Enabled = False

Else

DestroyReg.Enabled = True

Combo1.Enabled = True

Browser.Enabled = True

Rename.Enabled = True

Path.Enabled = True

Discrip.Enabled = True

ListExt.Enabled = True

Label1.Enabled = True

Label2.Enabled = True

Label3.Enabled = True

Label4.Enabled = True

End If

End Sub

Public Sub CardShow (NumRegCard As Integer)

Path.Text = Registrations (NumRegCard). FileName

ListExt.Text = Registrations (NumRegCard). FileMask

Discrip.Text = Registrations (NumRegCard). Discription

CurIndex = NumRegCard

End Sub

Public Sub MemberCard ()

Registrations (CurIndex). FileName = Path.Text

Registrations (CurIndex). FileMask = ListExt.Text

Registrations (CurIndex). Discription = Discrip.Text

End Sub

Програми

рис 1.1

Рис. 2.2

Рис. 3.1. Основне вікно програми

Рис. 3.2. Меню "Правка"

Рис. 3.3. Вікно властивостей документа